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Abstract 

Modeling  efforts  for  future  space  operation  vehicles  at  the  United  States  Air  Force 
Research  Lab’s  Air  Vehicles  Directorate  have  been  focused  towards  the  in  flight  mission. 
To  better  serve  the  research  and  development  effort,  a  simulation  of  the  ground 
operations  is  required  allowing  for  trade-offs  within  turnaround  operations  and  between 
the  components  that  drive  those  procedures.  However,  before  a  simulation  can  be 
developed  a  conceptual  model  must  be  generated  to  guide  the  model  building  process. 

This  research  provides  a  baseline  conceptual  model  for  reusable  space  vehicles 
based  on  the  space  shuttle  as  the  only  operational  vehicle  of  its  kind.  The  model  is  built 
utilizing  the  Integrated  Definition  (IDEF)  methodology,  specifically  IDEF3.  IDEF3  is 
focused  towards  process-viewpoint  diagramming  and  layout.  The  model  is  developed 
using  the  hierarchical  development  capabilities  of  the  IDEF3  methodology  and  is  broken 
into  modules  allowing  for  greater  reuse  and  usability. 

This  model  captures  the  scheduled  maintenance  performed  to  turnaround  the 
space  shuttle  for  the  next  launch  but  does  not  contain  every  activity.  The  idea  was  to 
capture  the  baseline  activities  that  may  be  found  in  future  Reusable  Space  Vehicles  and 
provide  a  description  of  what  happens  at  Kennedy  Space  Center  when  preparing  the 
space  shuttle  for  the  next  launch. 
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REUSABLE  SPACE  VEHICLE  GROUND  OPERATIONS 
BASELINE  CONCEPTUAL  MODEL 


I.  Introduction 


Overview 

The  Air  Vehicles  Directorate  (VA)  of  Air  Force  Research  Laboratory  (AFRL)  has 
focused  a  large  portion  of  its  research  and  development  (R&D)  towards  the  development 
of  a  space  operations  vehicle  (SOV)  to  support  the  Air  Force’s  Global  Engagement  core 
competency.  Simulation  based  R&D  is  one  tool  used  by  VA  to  identify  technologies 
required  to  meet  Air  Force  performance  requirements.  This  research  will  develop  a 
conceptual  model,  the  baseline  for  a  simulation  that  will  be  utilized  to  perform  trade-off 
studies  of  alternative  system  components  and  aid  in  the  choice  of  materials. 

In  order  to  develop  a  model  that  can  be  verified  and  validated,  AFRLA^A  is 
utilizing  the  space  shuttle  and  an  aircraft  similar  to  the  B-2  Spirit  Stealth  Bomber  as 
baselines.  The  space  shuttle  is  an  example  of  a  successful  reusable  space  vehicle  (RSV) 
and  the  B-2  is  an  example  of  a  system  with  assets  and  specialized  surface  materials 
requiring  greater  inspection  time  with  a  relatively  fast  turnaround.  In  order  to  use  the 
space  shuttle  as  a  baseline,  the  model  must  include  processes/activities  from  landing  to 
take-off.  The  National  Aeronautics  and  Space  Agency  (NASA)  has  developed  a 
simulation  for  take-off  to  landing  of  the  space  shuttle,  however,  NASA’s  touchdown  to 
take-off  (recycling)  simulation  has  insufficient  detail  to  perform  technology  trade-offs. 
AFRL’s  Human  Effectiveness  Directorate  as  well  as  several  defense  contractors  have 
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developed  simulations  for  the  reeyeling  of  SO  Vs.  Unfortunately,  the  results  of  trade-off 
studies  vary  widely  depending  upon  whieh  alternative  was  utilized  and  have  not  been 
validated  against  aetual  systems.  Additionally,  the  simulations  have  not  been  developed 
to  the  detail  required  by  VA  in  order  to  eonduet  the  analysis  they  desire. 

Problem  Statement 

In  order  to  develop  a  detailed  simulation  for  the  reeyeling  of  the  spaee  shuttle,  a 
eoneeptual  model  must  be  developed.  The  eoneeptual  model  provides  validation  of  the 
proeesses  that  are  later  transformed  into  a  working  simulation  (Paee  2002).  This  researeh 
will  develop  a  baseline  eoneeptual  model  for  landing  to  take-off  of  a  generie  RSV 
utilizing  the  spaee  shuttle  ground  operations  as  a  guide. 

Research  Question 

What  is  the  best  way  to  provide  an  effeetive  eoneeptual  model  to  support  the 
development  of  a  SOV  simulation  and  what  spaee  shuttle  reeyeling  proeedures  should  be 
modeled? 

Research  Scope 

The  seope  of  this  researeh  involves  baseline  examinations  that  inelude  an 
understanding  of  eoneeptual  design  methodologies.  In  addition,  this  study  will  foeus  on 
gathering  data  on  eurrent  operations  for  spaee  shuttle  turnaround  and  a  review  of 
proposed  SO  Vs.  This  study  is  limited  to  the  eurrent  ground  operations  and  logisties  for 
the  spaee  shuttle  both  inside  and  outside  the  Orbiter  Proeessing  Faeility  (OPF). 
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Investigative  Questions 

In  order  to  address  this  problem,  eertain  investigative  questions  were  eonsidered. 

1 .  What  is  simulation  based  researeh  and  development;  how  does  it  relate  to 
simulation  based  aequisition;  and  how  does  it  support  aequisition  reform 
initiatives? 

2.  Where  has  the  researeh  into  RSV  development  been  direeted? 

3.  Proeess  simulation  ean  be  used  for  analysis  but  requires  modeling  to  delineate  the 
eriteria  required:  What  form  should  this  model  take  and  how  should  it  be 
developed.  The  following  sub  questions  ean  be  used  to  evaluate  this  question. 

o  What  is  the  purpose  of  eoneeptual  modeling? 
o  What  makes  a  eoneeptual  model? 

o  What  are  the  proeedures  for  developing  a  eoneeptual  model? 
o  What  are  the  proeedures  for  verifying  and  validating  a  eoneeptual  model? 
o  How  have  eoneeptual  models  been  used  in  the  past? 
o  What  graphieal/visualization  methods  ean  be  used  for  displaying 
eoneeptual  models? 

4.  What  are  the  performanee  requirements  for  RSVs  that  drive  the  detail  level 
required  for  model  development?  The  following  sub  questions  ean  be  used  to 
evaluate  this  question. 

o  What  proeedures  eomprise  ground  operations  on  the  spaee  shuttle  from 
landing  to  take-off:  what  spaee  shuttle  operations  would  be  of  interest  for 
the  purpose  of  developing  a  generalized  model  for  RSVs? 
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Research  into  this  problem  will  be  directed  by  a  need  to  answer  these  questions 
while  keeping  the  overall  objective  in  mind:  development  of  a  baseline  conceptual  model. 
The  need  to  produce  a  validated  conceptual  model  will  be  paramount  to  the  ability  of  the 
model’s  usefulness  in  developing  future  simulations  that  can  be  verified.  Additionally, 
an  understanding  of  what  components  of  the  turnaround  process  are  important  to  model 
development  will  enable  the  model  to  be  reduced  and  made  as  simple  as  possible.  An 
understanding  of  concepts  affecting  process  flows  will  be  necessary  in  order  to  gain  a 
better  understanding  of  the  operations  being  examined.  In  preparing  this  model,  on-site 
observations  of  operations  and  their  physical  make-up  and  layout  will  enhance  the 
understanding  of  operational  flows  for  the  space  shuttle  in  particular. 

Summary  and  Conclusion 

This  chapter  presented  background  information  on  and  a  description  of  the 
problem  being  addressed  demonstrating  the  need  for  research  and  analysis.  A  problem 
statement  was  given  along  with  the  overarching  research  objective  used  to  direct  the 
study.  Several  investigative  questions  were  introduced  that  will  be  expanded  upon  in  the 
following  chapters.  Chapter  2  will  present  the  motivation  for  developing  a  conceptual 
model  and  discuss  areas  of  concern  when  examining  a  production  or  maintenance  process. 
Chapter  3  will  detail  the  conceptual  model  development  methodology  and  present  the 
data  analysis  methodology.  Chapter  4  will  explain  the  data  analysis  and  present  the 
results  in  the  form  of  a  conceptual  model.  Chapter  4  will  finish  with  a  validation  of  the 
baseline  model  followed  by  Chapter  5  which  will  provide  a  brief  conclusion  and  list  areas 
of  further  research  for  taking  this  effort  to  the  next  level. 
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II,  Literature  Review 


Introduction 

Much  work  is  being  accomplished  to  determine  what  the  next  generation  space 
vehiele  will  be  and  what  systems  and  eomponents  would  be  best  suited  to  serve  in  this 
endeavor.  NASA  is  keeping  their  options  open  when  considering  RSVs:  either  lifting 
body,  winged,  or  capsule  design.  For  VA,  the  options  considered  are  all  winged.  With 
the  spaee  shuttle  being  the  only  operational  RSV,  an  effort  to  develop  a  eoneeptual  model 
for  RSV  ground  turnaround  procedures  would  be  remiss  without  heavy  concentration  on 
the  space  shuttle  operations  at  Kennedy  Spaee  Center  (KSC). 

When  reviewing  the  literature,  several  topics  surface  that  need  discussion  when 
analyzing  any  process.  These  areas  are  as  follows:  risk  management,  seheduling, 
eapacity,  proeess  management,  and  layout/location  planning.  Other  areas  of  interest  in 
this  research  are  aequisition  reform  (to  include  simulation  based  R&D  and  simulation 
based  aequisition),  future/proposed  RSVs,  and  the  space  shuttle.  After  gaining  a  clear 
understanding  of  these  topics,  it  is  possible  to  continue  this  study  and  develop  a  useful 
conceptual  model  for  future  RSVs  based  on  the  space  shuttle. 

General  Topics 

Risk  Management. 

Risk  Management  is  defined  by  the  Software  Engineering  Institute  as  a  practice 
with  proeesses,  methods,  and  tools  for  managing  risks  in  a  projeet.  It  provides  a 
disciplined  environment  for  proactive  decision  making  to  assess  continuously  what  could 
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go  wrong  (risks),  determine  whieh  risks  are  important  to  deal  with,  and  implement 
strategies  to  deal  with  those  risks. 

Additionally,  DoD  Direetive  5000.1  "Defense  Aequisition"  (Department  of 
Defense  2003)  mandates  a  "streamlined  management  strueture  and  event-driven 
management  proeess  that  emphasizes  risk  management.”  This  ineludes  risks  assoeiated 
with  worker  safety,  environmental  eoneerns  sueh  as  pollution  or  ehemieal  spills,  and 
those  assoeiated  with  material  trade-offs  that  might  affeet  erew  or  payload  safety. 
Additionally,  there  are  eoneerns  for  program  existenee  due  to  mishaps  or  publie  opinion. 
Government  funding  may  be  lost  or  private  sponsors  and  stakeholders  may  loose  interest 
or  possibly  want  to  distanee  themselves  from  the  program.  Publie  relations  ean  be  a 
signifieant  player  in  the  risk  assessment  matrix. 

In  order  to  inelude  risk  management  in  the  deeision  making  proeess,  one  must 
know  what  the  risks  are.  Several  questions  ean  be  used  to  define  risks  (Cox  2002): 

What  is  the  souree  of  the  risk? 

What  or  who  is  the  target  that  is  at  risk? 

What  is  the  adverse  effeet  of  eoneern  that  the  souree  may  eause  in  exposed 

targets? 

By  what  eausal  meehanism,  does  the  souree  inerease  the  probability  of  the  effeet 

in  exposed  targets? 

Answering  these  questions  will  define  possible  risks  to  inelude  the  souree,  who  or  what  is 
at  risk,  the  “eost”  assoeiated  with  the  risk,  and  any  potential  eauses.  However,  risk 
management  enters  the  foray  as  an  external  eoneern.  For  this  study  risk  management  will 
remain  in  the  baekground  without  detailed  diseussion  or  examination.  Risk  management 
will  be  more  benefieial  when  eondueting  trade-off  analysis  for  various  eomponents. 
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systems,  and  subsystems  to  be  ineluded  in  whatever  RSV  is  eventually  seleeted.  Risk 
management  will  provide  the  benefit-to-eost  ratio  used  make  judgments  upon.  Various 
risks  and  outeomes  eould  be  represented  as  stoehastie  distributions  within  a  model  in 
order  to  provide  a  more  aceurate  representation  of  the  real  world. 

Scheduling. 

Seheduling  ean  be  defined  as  “the  alloeation  of  resourees  over  time  to  aeeomplish 
speeifie  tasks”  (Krajewski  and  Ritzman  2001).  Conway  et  al  deseribe  seheduling  “as  the 
task  of  eonstructing  an  ordering  of  the  operations  associated  with  each  machine" 
(Conway,  Maxwell  et  al.  1967).  With  the  latter  definition  eomes  the  idea  of  sequencing 
which  is  said  to  exist  whenever  the  order  of  operation  between  several  tasks  is  a  matter  of 
choice  (Conway,  Maxwell  et  al.  1967).  It  is  clear  that  many  sequencing  or  scheduling 
problems  are  solved  daily  and  by  everyone;  however,  many  do  not  see  or  recognize  the 
choices  they  make  as  such.  When  getting  up  in  the  morning,  there  are  several  tasks  that 
are  not  order  dependent — such  as  brushing  teeth,  showering,  and  shaving.  Some  tasks 
such  as  brushing  hair  and  showering  do  require  a  specific  order  and  are  thus  a  sequencing 
problem.  These  examples  are  quite  simplistic  in  nature  and  do  not  require  much  thought 
or  planning,  but  there  are  more  involved  problems  that  have  been  examined  by  many  and 
use  various  heuristics  or  sophisticated  algorithms  to  garner  near-optimal  or  optimal 
solutions. 

Portougal  and  Robb  say  that  scheduling  occurs  within  various  environments  with 
four  characteristic  factors:  planning  level,  production  type,  production  strategy,  and 
production  cycle  time.  The  planning  level  refers  to  the  level  within  the  corporate 
hierarchy  the  planning  occurs.  Generally,  two  levels  are  used  formally  (company  and 
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shop  floor)  with  the  aggregate  level  being  eonducted  informally  between  the  two 
(Portugal  and  Oliver  1996).  Produetion  type  refers  to  relationships  between  variety, 
volume,  and  proeess.  The  next  eharacteristie,  production  strategy,  refers  to  the  choice 
between  make  to  order  and  make  to  stock.  Production  cycle  time  is  the  last 
characteristic,  and  is  the  key  to  determining  whether  scheduling  theory  is  applicable  and 
would  be  beneficial  to  planning  and  scheduling  (Portugal  and  Oliver  1996). 

Based  on  their  research,  Portougal  and  Robb  suggest  only  systems  with  long  cycle 
environments  would  benefit  from  scheduling  theory  applications  to  the  more  complex 
nature  of  processes  with  cycle  times  longer  than  the  planning  period.  When  a  process  can 
be  completed  within  its  planning  period,  scheduling  is  less  complicated  and  does  not 
require  the  aid  of  sophisticated  algorithms.  Portougal  and  Robb  base  this  conclusion 
partly  on  the  fact  that  all  theoretical  scheduling  problems  assume  long-cycle 
environments  suggesting  a  disconnect  between  what  is  seen  in  practice  and  what  is 
proposed  and  analyzed  in  research  (Portugal  and  Oliver  1996). 

Scheduling  is  similar  to  a  job  shop  method  since  the  operations  at  KSC  involve 
the  space  shuttle  remaining  stationary  within  the  OPF  with  maintenance  personnel 
coming  to  the  shuttle.  Although  the  shuttle  remains  stationary  during  the  maintenance 
effort,  some  components  are  removed  and  taken  to  other  facilities  for  further  processing. 
Much  of  the  scheduling  will  be  constrained  by  various  facilities  with  limited  space,  level 
of  hazard  or  risk,  and  number  of  personnel  or  by  personnel  who  perform  certain  tasks. 

Within  a  work  or  process  flow  is  the  sequence  of  operations  or  tasks  guided  by 
various  constraints.  The  routing  scheme  is  the  path  or  flow  that  is  followed.  This  scheme 
can  either  be  mandatory  (all  steps  are  prescribed  and  followed  in  specific  order)  or 
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flexible  (several  alternative  flows  are  allowed  as  long  as  the  eonstraints  are  not  violated). 
The  shuttle  operations  would  involve  a  mix  of  both  routing  sehemes.  There  are  some 
tasks  that  are  prerequisites  to  others  and  some  that  are  performed  in  parallel  and  others 
that  ean  be  performed  at  any  time  within  the  turnaround  cyele  (Kumar  and  Zhao  1999). 
Eaeh  vehicle  is  prepped  for  a  preplanned  mission  and  various  inspections  being 
completed  based  on  the  previous  mission.  An  example  would  be  the  use  of  additional 
internal  (inside  the  cargo  bay)  tanks  used  by  the  shuttle  to  extend  missions.  Not  all 
missions  would  require  the  tanks  and  thus  slightly  different  procedures  would  be  used. 
However,  much  of  the  turnaround  operations  would  be  the  same  for  every  mission 
assuming  no  unforeseen  problems  or  failures. 

Capacity. 

Scheduling,  layout,  and  resource  allocation  all  have  some  affect  on  or  are  affected 
by  capacity.  Portougal  and  Robb  list  four  definitions  for  capacity  that  they  have 
observed. 


•  Design  capacity:  the  maximum  output  that  a  production  unit  (PU)  has  been 
designed  to  produce. 

•  Effective  capacity:  the  maximum  possible  output  given  a  particular  production 
environment  and  its  accompanying  impediments  to  productivity. 

•  Demonstrated  (historical)  capacity:  the  typical  real-life  output  rate  of  a  PEI. 

•  Agreed  capacity:  the  actual  capacity  negotiated  between  directors  of  PU  (Portugal 
and  Oliver  1996). 


Krajewski  and  Ritzman  (2002)  list  three  types  of  capacity  they  call  peak  capacity 
(maximum  output  a  process  or  facility  can  produce  under  ideal  conditions),  rated  capacity 
(an  engineering  assessment  based  on  continuous  operation  with  allowance  for  normal 
maintenance  and  repair  time),  and  effective  capacity  (the  maximum  output  a  process  or 
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firm  can  economically  sustain  under  normal  eonditions).  Capaeity  ean  either  be  a 
eonstraint  in  the  ease  of  bottleneeks  or  ean  be  a  tool  to  limit  the  affeets  of  variability  in 
the  ease  of  exeess  eapaeity.  Sometimes  additional  resourees  or  eapaeity  are  maintained 
for  periods  of  inereased  demand.  Safety  stoek  is  an  aeeepted  method  to  proteet  against 
variable  demand  or  searee  resourees  during  periods  where  demand  fiuetuates.  For  the 
military,  this  might  eoneern  the  keeping  of  eertain  aireraft  or  personnel  in  order  to  meet 
the  requirements  of  eurrent  defense  and  national  seeurity  polieies.  The  result  here  is 
exeess  eapaeity  and  inereased  eosts  that  require  justifieation  during  the  trade-off  analysis. 
Process  Management 

Mueh  of  the  previous  diseussion  falls  beneath  the  umbrella  of  proeess 
management.  Proeess  Management  is  “the  seleetion  of  the  inputs,  operations,  work 
flows,  and  methods  that  transform  inputs  into  outputs”  (Krajewski  and  Ritzman  2001).  A 
proeess  is  defined  as  “a  series  of  aetivities  that  produee  a  produet  or  serviee”  (MeNeese 
and  Marks  2001).  Input  seleetion  would  inelude  make  or  buy  deeisions,  operations 
seleetion  would  involve  the  ehoiee  of  proeess,  resourees,  and  layout  deeisions  although 
the  latter  may  be  a  one  time  deeision.  Proeess  management  would,  however,  foeus  on 
ongoing  deeisions  made  on  a  somewhat  regular  basis.  Proeess  management; 

foeuses  on  the  management  of  proeesses,  not  departments 

ineludes  primary,  seeondary,  and  work  (or  sub)  proeesses 

seeks  to  optimize  performanee  of  the  entire  system 

ensures  proeesses  are  standardized 

ensures  measurements  support  the  vision 

ensures  best  praetiees  are  examined 

foeuses  on  eustomer  satisfaetion 

ensures  eontinuous  improvement  and  measurable  value 
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represents  the  way  the  eompany  is  (MeNeese  and  Marks  2001) 


Workflow  management  involves  the  eoordination  and  eontrol  of  proeesses  and 
aetivities  of  people  and  systems  in  an  organization  (Kumar  and  Zhao  1999).  Workflow 
management  involves  information  proeessing  and  business  proeesses  two  of  three 
aetivities  eondueted  in  a  business;  the  third  is  material  proeesses.  Proeess  management 
would  eover  the  third  aetivity.  Although  the  two  seem  to  be  eomplementary,  there  are 
many  similarities  as  to  how  they  handle  their  basie  tasks  and  operations.  To  some 
degree,  workflow  management  will  have  its  greatest  benefit  in  the  feedbaek  loops  that 
allow  for  improved  eommunieation. 

Proeess  management  has  within  its  seope  sueh  teehniques  as  total  quality 
management  and  eontinuous  improvement.  There  are  five  eommon  elements  of  proeess 
management  sueeess  (Ittner  and  Lareker  1997): 

-  proeess  focus 

human  resource  management  practices 
information  utilization 
customer/supplier  relations 
organizational  commitment 

Process  focused  management  lends  itself  towards  improvement  and  organizational 
structures  based  on  functions  or  processes.  Human  resource  management  practices  that 
lend  themselves  towards  greater  training  and  education  as  well  as  a  team-oriented 
environment  are  better  suited  towards  process  improvement.  Information  utilization 
deals  with  the  reduction  of  variability  and  waste  through  the  facilitation  of  problem 
solving.  An  emphasis  on  workflow  management  could  enhance  the  utilization  of 
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information.  The  last  two  areas  deal  with  improved  supply  ehain  relationships  and  with 
senior  leader  involvement.  The  first  three  items  relate  more  to  this  researeh  based  on  its 
proeess  oriented  view  and  the  underlying  eonsideration  of  human  resouree  management 
praetiees  and  polieies  that  affeet  the  flow  and  are  not  inherently  evident. 

Layout/Location  Planning. 

When  eonsidering  loeation  there  are  several  aspeets  to  examine — sueh  as  where 
to  loeate  based  on  resourees  available,  environmental  eoneerns,  and  type  of  orbit  desired. 
The  layout  of  faeilities,  and  within-faeilities,  eoneerns  the  aetual  physieal  layout  at  the 
ehosen  loeation.  Depending  upon  various  physieal  features,  the  physieal  layout  at  a 
ehosen  loeation  (sueh  as  topography)  eould  have  signifieant  effeet  on  possible  faeility 
layout. 

The  layout  of  various  work  eenters  and  faeilities  eould  beeome  the  souree  of 
eonstraints  as  well  as  the  laek  of  available  resourees  due  to  loeation  ehoiee.  Aeeording  to 
(Krajewski  and  Ritzman  2001),  layout  ehoiees  ean  affeet: 

flow  of  materials  and  information 
utilization  of  labor  and  equipment 
eustomer  eonvenienee  and  sales 
worker  safety 
worker  morale 
eommunieation 


Four  types  of  layouts  are  used  in  general.  The  first  is  the  produet  layout  in  whieh 
a  linear  path  is  used  between  workstations  and  departments.  This  layout  is  well  suited  to 
repetitive  or  eontinuous  produetion.  The  seeond  type  is  the  proeess  layout  where 
grouping  of  workstations  or  departments  is  aeeomplished  by  funetion.  This  layout  is  well 
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suited  for  low  volume  environments  typical  of  job  shops.  In  some  cases,  a  mixed  or 
hybrid  layout  is  used.  This  layout  combines  some  aspects  of  the  process  and  the  product 
layouts  to  achieve  operational  goals.  The  last  type  of  layout  is  the  fixed-position  layout. 

In  the  case  of  the  shuttle,  only  two  locations  were  considered  for  possible  launch 
sites  (Vandenberg  AFB,  CA  and  KSC)  with  KSC  being  the  only  location  ever  used.  This 
decision  was  based  in  part  on  the  facilities  already  present,  but,  topography  played  an 
important  role.  For  these  locations,  their  positions  near  a  large  bodies  of  water  where 
launches  could  take  place  over  non-populated  areas  and  allowed  for  the  possibility  of 
easterly  orbits  from  KSC  and  polar  orbits  from  Vandenberg  (Graham  and  Jones  1982). 

Weather  considerations  were  also  considered  since  poor  weather  can  result  in 
delays  depending  on  facility  choices  and  will  affect  launch  and  return  dates  most.  Most 
of  the  assembly  occurs  within  various  facilities  and  structures  protected  from  the  effects 
of  weather.  A  real  concern  at  KSC  is  the  hurricane  season,  though  this  does  not  happen 
often  enough  to  drastically  affect  operations.  However,  ground  ops  at  KSC  would  not  be 
hindered  by  weather  since  assembly  occurred  out  of  the  elements. 

Acquisition  Reform 

The  DoD  has  moved  from  a  bottoms-up  to  a  top-down  approach  to  determine 
capability  requirements.  The  newly  released  DoD  Directive  5000  Series  document  the 
new  approach  to  system  acquisition  including  emphasis  on  joint  capabilities,  teamwork, 
lifecycle  cost,  and  best  practices.  Acquisition  Reform  Initiatives  support  the  DoD’s  need 
to  acquire  new  capabilities  quickly  and  control/reduce  life  cycle  costs. 
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In  order  to  transition  to  this  new  business  model,  the  Air  Foree  developed 
initiatives  such  as  Cost  as  an  Independent  Variable,  Lightning  Bolts,  Reduction  in  Total 
Ownership  Cost  and  Lean  Aerospace  Initiative.  These  initiatives  present  methods  to 
reducing  total  ownership  cost,  total  cycle  time,  and  provide  tools  to  successfully  acquire 
new  Air  Force  capabilities  quickly  at  an  acceptable  cost. 

Simulation  Based  Acquisition. 

Simulation  Based  Acquisition  (SBA)  is  a  concept  where  an  integrated, 
collaborative  process  is  used  for  planning  and  execution  of  an  acquisition  program.  SBA 
is  a  collaborative  environment  where  all  parties  involved  in  the  acquisition  process  work 
together,  independent  of  the  physical  location,  to  solve  problems  and  develop  processes 
during  all  phases  of  acquisition. 

SBA  is  seen  as  a  tool  for  the  program  manager  which  will  reduce  risk  in  cost, 
schedule  and  performance  through  (F allin  1997): 

Continuous  evaluation  of  system  development. 

Rapid  evaluation  of  concept  design. 

Reduce  and  delay  need  for  physical  prototype. 

Facilitate  continuous  user  participation  in  development  process. 

Efficient  development/evaluation  of  manufacturing  plans. 

Reuse  of  system  software  and  hardware  in  training  simulators. 

Ability  to  test  proposed  system  at  sub-component,  component,  and  system 

level. 

The  effectiveness  of  SBA  versus  standard  acquisition  methodology  was  tested  in 
a  study  performed  at  the  Defense  Systems  Management  College  (Brown  1999).  An 
acquisition  project  was  developed  to  design,  manufacture,  and  test  prototype  vehicles 
meeting  a  specific  set  of  manufacturing  and  performance  criteria.  The  students  of  the 
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Advanced  Program  Management  eourse  (APMC)  were  divided  into  groups,  one  of  which 
was  a  control  group. 

Each  group  was  provided  with  an  Operational  Requirements  Document  and 
Statement  of  Work.  Eaeh  group  reeeived  the  same  materials  with  the  exeeption  of 
software.  The  eontrol  group  was  provided  with  standard  modeling  software  used  in 
previous  APMCs  ineluding  information  relative  to  one  system  requirement.  This 
software  model  ineluded  only  basie  design  equations.  On  the  other  hand,  the  advanced 
groups  were  provided  an  advaneed  design  and  simulation  tool  that  not  only  evaluated 
design  for  performanee,  but  also  relative  to  eost,  weight,  and  produeability. 

Though  on  average,  the  additional  modeling  and  simulation  (M&S)  eost  drove  up 
the  concept  development  and  demonstration  eosts,  from  a  total  life  cyele  perspeetive 
simulation  based  aequisition  delivered  a  more  mature,  produeible  design.  The  author  did 
note  one  drawbaek  to  M&S.  When  a  eompetitive  environment  was  added  to  the  mix,  the 
group  used  M&S  to  “gain  a  eompetitive  advantage,  not  to  reduee  development  eost  and 
sehedule.”  Eigures  1-4  show  the  results  of  this  study. 
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Producibility  Index  (PI)  =  (#  types  of  parts)  *  (#  total  parts) 
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Figure  1,  Cost/Producability  Comparison 

(Brown  1999) 


M&S  Designs  Engineering  Changes 


Figure  2,  Development  Comparison 

(Brown  1999) 
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Figure  3,  Performance  Comparison 

(Brown  1999) 


Tests  Passed  Passed  All  Tests 


Figure  4,  Runoff  Comparison 

(Brown  1999) 


Simulation  Based  Research  &  Development. 

Simulation  based  Research  &  Development  (SBR&D)  is  a  methodology  that 
utilizes  a  common  computer  environment  for  the  development  of  new  aerospace  concepts 
prior  to  Milestone  B,  concept  development  through  design  to  testing  (Air  Force  Research 
Laboratory  2002).  SBR&D  therefore  supports  the  DoD’s  Integrated  Product  and  Process 
Development  (IPPD)  management  process  and  its  use  of  multidisciplinary  teams  to 
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optimize  the  design,  manufaeture,  business,  and  supportability.  IPPD  emphasizes 
eoneurrent  development  of  produet  and  proeesses,  early  and  eontinuous  life  eyele 
planning,  multidiseipbnary  teamwork,  proaetive  identifieation  and  management  of  risk 
(Department  of  Defense  1999). 

SBR&D  eombines  a  variety  of  M&S  as  well  as  researeh  and  teehnology- 
development  tools  (engineering-level  modeling,  design,  and  analysis  tools,  mission-and 
eampaign-level  simulations,  eost  analysis  tools,  and  database  tools)  into  a  common 
computer  environment  (Zeh  and  Schumacher  2001).  Through  the  integration  of  these 
tools,  a  common  synthetic  battlespace  is  developed  (Zeh  and  Schumacher  2001).  New 
and  current  aerospace  systems  can  be  inserted  into  the  battlespace  where  cost  and 
performance  trade-off  studies  are  accomplished  to  evaluate  the  potential  benefits  of  new 
technology  capabilities.  The  three  primary  goals  of  SBR&D  are  (Zeh  and  Schumacher 
2001): 

Guide  Air  Force  Science  and  Technology  (S&T)  investment 

Reduce  R&D  time  and  cost  to  develop  and  mature  promising  technologies 

Integrate  the  Warfighter  and  technologist  into  the  S&T  acquisition  process. 

Future  Reusable  Space  Vehicles. 

An  on-going  effort  to  demonstrate  the  possibility  of  creating  a  quick  turnaround 
spacecraft  for  commercial  use  has  been  underway  under  the  title:  X-Prize.  This 
competition  is  based  on  previous  competitions  of  the  past  that  gave  monetary  prizes  to 
the  first  individual  or  group  that  completed  a  specific  event,  such  as  a  non-stop  solo  flight 
across  the  Atlantic  Ocean.  Although  Lindberg  received  $25,000  for  his  feat,  the  X-Prize 
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is  set  to  award  $10,000,000  for  the  first  to  fly  a  vehiele  to  a  height  of  62.5  miles  above 
the  earth  with  three  passengers  (or  one  pilot  and  the  equivalent  weight  of  two  passengers) 
and  repeat  the  event  within  14  days.  The  amount  of  prize  money  and  purpose  for  the 
eompetition  is  in  part  designed  to  generate  publie  interest  in  spaee  flight  (CNN  2003). 
Table  1  provides  an  overview  of  the  various  take-off  and  landing  scenarios  under 
development  for  the  X-prize  competition  as  well  as  the  number  of  stages  considered. 
Table  2  provides  a  brief  overview  for  the  commercial  and  public  sectors  vehicles. 


Table  1.  X  Prize  Contenders 


Take-off  Scenario 

Qty 

Landing  Scenario 

Qty 

#  Stages 

Qty 

Vertical 

8 

Vertical 

1 

Single 

5 

Horizontal 

4 

Horizontal 

11 

Two 

2 

Carrier  craft 

8 

Parachute/foil 

6 

Multiple 

1 

.  (FAA2000) 


Table  2,  Public  and  Private  Sector  RSVs 


Take-off  Scenario 

Qty 

Landing  Scenario 

Qty 

#  Stages 

Qty 

Vertical 

8 

Vertical 

1 

Single 

5 

Horizontal 

4 

Horizontal 

11 

Two 

2 

Carrier  craft 

8 

Parachute/foil 

6 

Multiple 

1 

(FAA  2000) 


19 


Much  of  what  is  under  development  is  for  eommereial  use  whether  it  is  for  spaee 
tourism,  payload  delivery,  or  a  eombination  of  both.  The  key  problem  to  sueeessful 
implementation  of  a  eommereially  viable  vehiele  is  the  reduetion  of  eost  (Kaplan  2002). 
One  of  the  areas  driving  up  the  eost  for  RSVs  is  the  eost  per  launeh.  One  way  to  reduee 
this  eost  is  to  enable  faster  turnaround  and  inerease  the  number  of  available  launehes. 
Even  the  spaee  shuttle  was  initially  projeeted  to  have  mueh  shorter  turnaround  times  than 
what  eurrently  exists. 

The  shuttle  was  initially  planned  to  have  40  missions  per  year  and  have  a 
turnaround  time  of  160  hours(Jenkins  2002).  Before  the  Challenger  ineident  in  1986,  the 
shuttle  was  on  target  for  16  missions.  After  Challenger,  the  target  has  settled  down 
around  seven  and  may  deerease  onee  more  after  Columbia.  The  eurrent  thought  on 
launeh  vehieles  is  to  have  turnaround  times  as  short  as  48  hours  with  a  24  hour  surge 
eapaeity  with  times  no  longer  than  14  days.  The  Air  Foree  in  partieular  is  looking  for 
high  sortie  rates  in  the  neighborhood  of  20  per  two-week  period  (Wall  2002). 
Additionally,  many  of  the  eoneepts  eall  for  smaller  erews  to  handle  the  turnaround 
operations  espeeially  as  eompared  to  the  numbers  surrounding  spaee  shuttle  operations. 

Mueh  of  the  literature  on  RSVs  foeused  on  the  information  eontained  in  Tables  1 
and  2  above.  Additionally,  diseussions  have  begun  to  look  at  the  support  and  ground 
operations  of  RSVs.  Sinee  no  speeifie  type  of  vehiele  has  been  seleeted  as  the  “one” 
design  to  develop,  this  researeh  will  not  foeus  on  anyone  type  nor  leave  out  eomponents 
that  may  be  spaee  shuttle  unique. 
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III.  Methodology 


Overview 

The  overarching  design  behind  this  research  is  a  case  study  lending  itself  to  task 
and  contextual  analysis.  This  study  will  focus  on  the  ground  operations  of  the  space 
shuttle  as  an  example  of  RSV  operations.  Being  inductive  in  nature,  this  study  will  be 
concerned  with  the  construction  of  a  descriptive  model.  No  intent  is  given  at  this  point  to 
compare  alternatives  only  to  examine  the  processes  as  they  currently  exist  and  provide  a 
description  in  the  form  of  a  conceptual  model. 

This  chapter  will  discuss  conceptual  models  and  what  is  required  to  present  a 
useful  model.  The  need  for  a  model,  its  purpose,  and  its  characteristics  will  be  discussed. 
Additionally,  the  methodology  chosen  for  the  layout,  documentation,  and  building  of  the 
conceptual  model  will  be  presented  followed  by  a  brief  examination  of  how  the  data  will 
be  handled.  A  detailed  analysis  of  the  data  and  how  the  conceptual  model  was  built  will 
be  presented  in  Chapter  4. 

Conceptual  modeling 

A  conceptual  model  aids  in  scope  of  reuse  and  in  the  development  of  simulation 
models  created  from  the  conceptual  model.  The  value  of  quality  conceptual  model  can 
be  seen  in  the  fact  that  some  simulation  requirements  may  be  “incomplete,  unclear, 
inconsistent,  and  sometimes  wrong”  (Pace  2002).  A  conceptual  model  provides  a  great 
benefit  for  the  simulation  developer  but  is  still  hampered  by  the  experience  and 
knowledge  of  the  builder.  “Regardless  of  how  it  is  defined,  model  conceptualization  is 
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considered  as  mueh  an  art  as  a  seience”  (Rohrer  and  Banks  1998).  The  goal  is  to  reduce 
the  multitudes  of  data  to  useable  and  manageable  pieees  that  are  separate  from  the  noise 
and  other  distractions.  A  certain  but  not  easily  definable  level  of  abstraetion  is  desired 
from  the  proeess.  Benjamin  et.  al.  list  three  levels  of  abstraetion  to  aid  in  simulation 
model  development:  (i)  Domain  Level,  (ii)  Model  Specifieation,  and  (iii)  Execution  and 
Analysis  Level  (Benjamin,  Delen  et  al.  2000). 

The  Domain  Level  ineludes  information  about  proeesses  and  their  relationships. 
The  descriptions  may  either  be  proeess-oriented  or  objeet-oriented.  The  Design  Level 
eontains  information  needed  to  build  the  simulation  model  such  as  input  requirements, 
experimental  design  requirements,  and  data  required  to  build  the  simulation.  The  final 
product  from  this  level  is  the  actual  simulation.  The  last  area.  Execution  and  Analysis 
Level,  includes  the  input  data  and  its  analysis,  the  simulation  runs,  and  output  from 
experimental  runs.  The  output  from  this  level  is  the  results  of  the  simulation  runs  and 
eonclusions  made  based  on  the  analysis  that  follows  execution.  This  may  include 


decisions  on  various  trade-offs.  The  following  figure  illustrates  the  three  levels. 


Figure  5,  Separation  of  Levels  Extends  Reuse  Scope 

(Benjamin,  Delen  et  al.  2000) 
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As  can  be  seen  in  this  diagram,  the  Domain  Analysis  is  aecomplished  before 
speeifying  a  simulation  model  and  gathering  detailed  information  about  input  data  and 
experimental  design.  This  level  is  just  a  basic  representation  of  the  system  to  be  modeled 
and  the  major  components.  Therefore,  the  foeus  of  this  researeh  effort  will  be  on  the 
Domain  Analysis  Level  providing  ontologieal  and  proeess  descriptions  as  necessary. 

Purpose 

Eeonomic  considerations  exist  emphasizing  the  importance  for  reuse  of 
simulation  components  (Pace  2000).  Considering  the  eost  of  model  development,  it  is 
wise  to  develop  models  based  on  previous  work  or  that  have  multiple  uses.  For  example, 
NASA’s  GEM-FLOW  is  a  generic  simulation  used  to  model  the  launch  and  in-flight 
operations  of  various  spaeecraft  to  inelude  traditional  lift  vehieles  and  the  space  shuttle. 

A  doeumented  conceptual  model  aids  in  reuse  or  use  in  combination  with  other 
simulations  by  allowing  others  to  know  the  baekground  of  the  model  allowing  clearer 
understanding  of  its  limitations  and  intended  purpose.  The  construction  of  a  conceptual 
or  structural  model  is  typieally  carried  out  by  an  analyst  as  an  undocumented  thought 
proeess  rather  than  as  an  explicitly  represented  design  activity  (Benjamin,  Delen  et  al. 
2000).  Simulations  ereated  in  this  ad  hoc  manner,  often,  do  not  include  doeumentation  of 
the  conceptual  model  if  it  even  existed  in  the  first  place.  As  a  result,  problems  are 
created  for  the  future  use  of  the  simulation  since  the  final  executable  simulation  is  the 
only  documentation. 

Description 

Coneeptual  models  tell  the  customer  what  the  system  will  do.  A  conceptual 
model  translates  modeling  requirements  into  a  detailed  design  framework  (Pace  2000) 
and  is  the  collection  of  information  that  describes  a  simulation  developer’s  coneept  about 
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the  simulation  and  its  pieces  (Pace  2000).  It  is  the  primary  mechanism  for  clear  and 
comprehensive  communication  among  simulation  developer  and  implementation 
personnel  (Pace  2000).  There  are  several  questions  that  can  be  answered  by  a  conceptual 
model  (adapted  from  (Pace  2000). 

What  objects  will  be  in  the  system? 

What  will  happen  to  the  objects  in  the  system? 

What  will  the  system  look  like  to  simulation  developers? 

What  choices  will  be  offered  to  simulation  developers? 

What  is  the  timing  of  events? 

What  will  the  output  look  like? 

A  conceptual  model  is  the  framework  upon  which  a  simulation  will  be  built. 

When  more  than  one  simulation  is  interconnected  into  a  system  it  is  called  a  Federation 
of  Models  and  Simulations  and  the  simulation  is  referred  to  a  Federate  (Department  of 
Defense  2003).  Conceptual  models  have  been  used  for  the  development  of  databases, 
software  programs,  and  clarifying  and  describing  processes  leading  to  the  development  of 
a  simulation  model.  However,  a  conceptual  model  can  itself  be  an  end  product  used 
primarily  for  the  purpose  of  description. 

The  characteristics  of  a  good  conceptual  design  include  the  use  of  customer 
language  not  jargon,  system  function  descriptions,  implementation  independence,  and 
linked  to  requirements  linkage.  A  conceptual  design  is  different  from  a  technical  design 
in  that  the  latter  tells  programmers  what  the  system  will  do  and  includes  major  hardware 
components  and  their  function,  hierarchy  and  function  of  software  components,  data 
structures,  and  data  flow. 
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A  conceptual  model  should  contain  three  eomponents:  simulation  context, 
mission  space,  and  simulation  space  (Defense  Modeling  and  Simulation  Office  2000; 
Pace  2000).  The  simulation  eontext  contains  the  laws  of  physics  and  principles  of 
engineering  included  in  a  physical  model.  Mission  space  refers  to  simulation  elements: 
entities,  assumptions,  algorithms,  charaeteristies,  relationships,  and  data.  The  simulation 
space  contains  additional  information  “needed  to  explain  how  the  simulation  will  satisfy 
its  objectives”  (Pace  2000).  The  mission  and  simulation  space  are  both  part  of  the 
simulation  concept.  These  components  can  be  seen  in  Figure  6  below: 


Figure  6,  Conceptual  Model  Components 

(Defense  Modeling  and  Simulation  Office  2000;  Pace  2000) 

Several  design  steps  for  conceptual  models  have  been  put  forth  by  various 
authors.  Benjamin  et  al  suggest  the  following  steps:  (i)  Determine  the  speeifie  goals  of 
the  simulation  study:  what  is  the  objective?  (ii)  Determine  the  object  roles,  boundary  and 
level  of  detail  seleeting  the  part  to  be  studied,  level  of  abstraetion,  and  identify  model 
objects  and  roles  (Defense  Modeling  and  Simulation  Office  2000;  Pace  2000). 

Pace  suggests  the  following  design  steps  (Defense  Modeling  and  Simulation 
Office  2000;  Pace  2000).  First,  the  model  builder  needs  to  collect  authoritative  info 
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about  the  context.  This  involves  creating  authoritative  descriptions  of  entities,  processes, 

and  situations.  It  “should  address  everything  needed  to  fully  describe  the  domain  of  the 

simulation”  (Defense  Modeling  and  Simulation  Office  2000).  When  less  is  known  about 

the  context,  the  effort  becomes  more  difficult.  The  next  step  is  to  identify  entities  and 

processes  referred  to  as  decomposition  of  the  mission  space.  This  step  is  where  decisions 

are  made  about  the  level  of  detail  and  drill-down  and  can  help  the  model  stay  with  the 

established  scope.  The  following  lists  several  principles  of  decomposition: 

There  should  be  a  specific  simulation  element  (parameter,  entity,  etc.)  for 
every  item  (parameter,  entity,  etc.)  specified  for  representation  in  the 
simulation  by  simulation  requirements. 

There  should  be  a  specific  simulation  element  (parameter,  entity,  etc.)  for 
every  item  (entity,  task,  parameter,  state,  etc.)  of  potential  assessment 
interest  related  to  the  purpose  of  the  simulation. 

There  should  be  “real  world”  counterparts  (objects,  parameters  for  which 
data  exist  or  could  exist,  etc.)  for  every  simulation  element  as  far  as 
possible.  The  potential  impact  of  data,  and  metadata  structures,  on 
simulation  elements  and  the  simulation  conceptual  model  should  not  be 
underestimated. 

Wherever  possible,  the  simulation  elements  should  correspond  to 
“standard”  and  widely  accepted  decomposition  paradigms  to  facilitate 
acceptance  of  the  conceptual  model  and  effective  interaction  with  other 
simulation  endeavors  (including  reuse  of  algorithms  and  other  simulation 
components). 

Simulation  elements  required  for  computational  considerations  (e.g.,  an 
approximation  used  as  a  surrogate  for  a  more  desirable  parameter  that  is 
not  computationally  viable)  that  fail  to  meet  any  of  the  previously  stated 
criteria  should  be  used  only  when  absolutely  essential. 

There  should  not  be  extraneous  simulation  elements.  Elements  neither 
directly  related  to  specific  items  in  the  simulation  requirements  nor 
directly  implied  by  potential  assessment  issues  and  elements  without  a 
specific  counterpart  in  the  real  world  or  in  standard  decomposition 
paradigms  should  not  be  included  in  the  simulation  conceptual  model. 

Every  extraneous  simulation  element  is  an  unnecessary  source  of  potential 
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simulation  problems  (Defense  Modeling  and  Simulation  Offiee  2000;  Paee 

2000). 


The  third  step  involves  developing  simulation  elements  neeessary  for  eaeh  entity  or 
proeess  detailed  in  the  previous  step.  “Simulation  elements  determine  functional  and 
behavioral  capabilities  of  the  simulation”  (Defense  Modeling  and  Simulation  Office 
2000).  The  last  step  is  to  define  interactions  and  relations  among  simulation  elements 
ensuring  all  the  relationships  among  simulation  elements  are  addressed.  Additionally,  all 
constraints  and  boundaries  set  by  the  domain  should  be  imposed  and  expressed  within  the 
requirements  (Defense  Modeling  and  Simulation  Office  2000;  Pace  2000). 

When  laying  out  the  model,  it  is  best  to  keep  it  structured  and  modular  allowing 
for  more  flexibility  and  more  rapid  development  (Rohrer  and  Banks  1998).  Although  the 
process  of  abstracting  from  reality  can  be  difficult,  it  is  best  to  have  some  structured 
approach  guiding  the  process. 

Documentation 

The  documentation  should  provide  a  “coherent  set  of  information  that  fully  and 
correctly  describes  the  conceptual  model  so  that  its  capabilities,  limitations,  and 
characteristics  can  be  readily  understood  by  simulation  development  personnel; 
verification,  validation,  and  accreditation  personnel;  and  by  subject  matter  experts 
involved  in  simulation  assessments”  (Pace  2000). 

When  completing  the  project,  there  are  several  items  to  include  in  final  product 
which  include  the  following; 

A  write-up  about  the  various  sub-systems  in  the  system 

A  set  of  conceptual  drawings  of  the  main  individual  components 
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A  technical  description  for  the  complete  system,  explaining  the  function  of  the 
system 

Detailed  costing  and  commercial  aspects  for  development  of  the  complete  system 

Recommendations 

Visualization 

Knowing  what  a  conceptual  model  is  and  what  to  include  still  leaves  one  question 
unanswered;  What  graphical/visualization  methods  can  be  used  for  displaying  conceptual 
models?  A  simplistic  method  would  be  the  use  of  flowcharts  describing  the  entities, 
processes,  and  flows  through  the  overall  process,  but  this  method  might  not  capture  the 
full  dynamics  of  the  system.  Flowcharts  would  be  best  suited  as  an  initial  step  in 
development  for  gathering  ideas  and  laying  out  a  general  flow — such  as  an  activity 
diagram  (Cochran  and  Wheaton  2002).  Still  another  methodology  exists  that  not  only 
provides  for  the  visualization  of  the  model,  but  satisfies  the  requirements  discussed  in  this 
chapter  for  the  development  of  a  quality  conceptual  model. 

Integrated  Definition  (IDEF)  Model 

The  methodology  that  satisfies  all  the  requirements  for  conceptual  model 
development  is  IDEF3.  IDEF  began  as  an  Air  Force  program  for  Integrated  Computer- 
Aided  Manufacturing  (ICAM)  where  the  first  ICAM  Definition  was  created  and  later 
recast  as  it  currently  stands  with  several  versions  now  available  (Mayer,  Menzel  et  al. 
1995).  IDEF  was  initially  created  to  be  a  set  of  methodologies  that  would  represent 
manufacturing  systems.  The  first  set  of  IDEF  methodologies,  IDEFO,  IDEF  I,  IDEF2, 
and  IDEF3,  were  developed  for  functional,  data,  dynamic  analysis,  and  process  modeling, 
respectively  (Kusiak  and  Zakarian  1996). 
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IDEFO  is  used  to  model  flows  with  an  emphasis  on  deeisions  and  aetions.  IDEF  0 
allows  for  proeess  deseriptions  with  the  inelusion  of  eontrol  meehanisms  that  affeet  and 
direet  the  flow  of  information  or  objeets.  IDEFl  was  designed  to  be  used  with  software 
and  eommunieation  model  development  and  analysis.  IDEF2  provides  for  the  deseription 
of  dynamie  systems  but  leaves  out  guidanee  on  graphieal  representations  allowing  the 
user  to  develop  models  using  language-speeifie  figures.  IDEF3  provides  for  proeess 
modeling  in  addition  to  objeet-oriented  views.  Several  other  methods  are  under 
development  or  being  proposed  but  are  not  geared  towards  proeess  modeling  whieh  is 
important  to  this  researeh  effort. 

Of  the  IDEF  methods  listed  above,  IDEFO  and  IDEF3  provide  the  most 
possibilities;  however,  IDEF3  provides  the  most  funetionality  and  is  better  suited  towards 
the  development  of  a  eoneeptual  model  of  physieal  proeesses.  The  Table  3  summarizes 
some  key  attributes  of  a  eoneeptual  model  and  how  it  is  addressed  by  a  IDEF3  model 
detailing  how  an  IDEF3  model  meets  the  eriteria  of  a  eoneeptual  model. 

Although  IDEF3  satisfies  the  ability  to  develop  ontologieal  in  addition  to  proeess 
deseriptions,  another  methodology,  IDEF5,  has  been  developed  to  build  ontologieal 
deseriptions.  The  differenee  is  that  IDEF3  provides  a  means  for  deseribing  proeesses  to 
inelude  preeedenee,  objeet  flow,  and  relational  links  (Kusiak  and  Zakarian  1996)  and  for 
the  deseription  of  entity  state  ehanges  detailing  the  proeesses  involved.  Being  a  more 
eapable  methodology,  IDEF3  has  been  ehosen  for  this  researeh  effort.  The  following 
table  will  eompare  the  IDEF3  methodology  to  the  attributes  of  a  eoneeptual  model.  The 
ehapter  will  eontinue  with  a  deseription  of  IDEF3  eomponents  and  a  brief  explanation  of 
the  development  proeess. 
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Table  3,  Comparison  of  Model  Attributes 


Attribute 

Model 

Conceptual  I  IDEF3 

1  Domain  Analysis  I 

Ontology  Descriptions 
Process  Descriptions 

Satisfies  Domain  Level 
analysis  which  is 
comprised  of 
ontological  and  process 
descriptions. 

1  Validation  (appropriateness)  | 

Completeness 

1/1  entity  to  process  ratio 
Simulation  space 
components  addressed 
Satisfies  specifications 
for  simulation 

Requires  one  unit  of 
behavior  (UOB)  or 
object  symbol  for  every 
activity/process  or 
object,  respectively 
Allows  for  more  data  in 
the  form  of  notes, 
elaborations,  file 
attachments,  and 
description  addressing 
simulation  space  and 
specifications 

Consisteney 

All  perspectives  are 
compatible 

Allows  for  both  object- 
oriented  and  process- 
oriented  views  utilizing 
the  same  components 

Coherenee 

All  elements  have  a 
function  and  can  be 
activated 

All  elements  must  have 
a  real  world  counterpart 

1  Characteristics  I 

Functional  descriptions 
Generalized  language;  no 
jargon 

Functional  descriptions 
Terminology  set  by  the 
modeler 

1  Three  components  | 

Simulation  context 
(physical  constraints) 
Mission  space  (entities, 
assumptions, 
relationships,  etc.) 
Simulation  space 
(additional  information 
needed  to  identify  how 
the  simulation  will 
satisfy  objectives) 

Physical  constraints  set 
by  links 

UOBs  and  other 
schematic  symbols 
cover  all  entities,  etc.; 
notes,  elaborations,  etc. 
cover  assumptions 
Elaborations,  notes, 
descriptions,  and  file 
attachments  allow  for 
addition  of  more  data 

1  Documentation  I 

Subsystem  write-up 
Conceptual  drawings 
Technical  system 
description 

Decompositions  allow 
for  subsystem  inclusion 
in  a  hierarchical  format 
IDEF3  schematics 
Elaborations,  notes, 
descriptions,  and  file 
attachments 

1  Viewpoints  | 

Event-oriented 

Object-oriented 

Event-oriented 

Object-oriented 
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IDEF3 

IDEF3  was  created  to  eapture  deseriptions  of  sequenees  of  aetivities  with  the 
primary  goal  of  providing  a  struetured  method  by  whieh  operational  and  system 
knowledge  ean  be  expressed  (Mayer,  Menzel  et  al.  1995).  An  IDEF3  model  serves  to 
detail  the  simulation  context  and  simulation  concept.  To  aehieve  this  goal,  an  IDEF3 
model  must  support  the  items  the  following  list  (adapted  from  (Mayer,  Menzel  et  al. 
1995). 

Seenarios  of  organizational  aetivities. 

Roles  of  entity  types  in  the  organizational  aetivities. 

Entity  seenarios  or  entity  interaetion  with  the  system  at  the  entity-function  level. 

System  response  to  entity  functions. 

Entity  classes  and  delineation  of  entity  elasses. 

Deelaration  of  timing,  sequeneing,  and  resource  eonstraints. 

Entity  interfaee  objeets  (e.g.,  tools,  test  equipment,  and  faeilities) 

Several  software  paekages  have  been  produced  that  produee  IDEE  produets. 

Meta  Software’s  Workflow  Modeler  produees  IDEFO  diagrams.  IDEFine  Etd  has 
developed  software  to  work  with  IDEFO  and  IDEE  lx.  However,  neither  of  these  would 
be  useful  in  this  endeavor  sinee  they  do  not  work  with  IDEF3.  For  this  work,  three 
software  paekages  were  examined.  Knowledge  Based  Systems,  Ine.’s  (KBSI)  ProSim, 
Computer  Assoeiates  International’s  AllFusion:  Proeess  Modeler,  and  Popkin  Software’s 
System  Arehitect.  All  three  produee  IDEF3  produets  with  the  latter  two  working  with 
IDEFO  as  well.  Of  the  three,  ProSim  was  the  most  user-friendly  providing  a  graphieal 
interfaee  and  eapability  for  exporting  to  MS  Visio,  MS  Projeet,  and  HTML  eoding  for 
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use  in  any  web  browser.  KBSI  is  the  prime  eontraetor  for  the  Armstrong  Laboratory, 

Human  Resourees  Direetorate,  Logisties  Researeh  Division,  Wright-Patterson  AFB,  OH 

for  the  development  of  IDEF  software,  ProSim.  Aeeording  to  KBSI,  the  following  are 

uses  of  the  IDEF3  methodology  (Mayer,  Menzel  et  al.  1995). 

Reeord  the  raw  data  resulting  from  faet-finding  interviews  in  systems  analysis 
aetivities. 

Determine  the  impaet  of  an  organization's  information  resouree  on  the  major 
operation  seenarios  of  an  enterprise. 

Doeument  the  deeision  proeedures  affeeting  the  states  and  life-eyele  of  eritieal 
shared  data,  partieularly  manufaeturing,  engineering,  and  maintenanee  produet 
definition  data. 

Manage  data  eonfiguration  and  ehange  eontrol  poliey  definition. 

Make  system  design  and  design  trade-off  analysis. 

Provide  simulation  model  generation. 

IDEF  3  Models  have  been  used  for  the  development  of  eoneeptual  models 
(Coehran  and  Wheaton  2002),  reliability  evaluation  (Kusiak  and  Zakarian  1996),  and 
simulation  development  (Benjamin,  Delen  et  al.  2000)  as  well  as  business  proeess 
reengineering  but  is  not  limited  to  these  efforts.  The  IDEF3  methodology  does  not 
eapture  all  aspeets  of  the  system  though  it  ean  be  used  in  eonjunetion  with  other  methods 
to  provide  a  very  detailed  deseription.  Although  other  methods  ean  be  added,  it  is 
essential  to  stay  within  the  seope  of  this  researeh  and  foeus  on  the  deseription  of  the 
proeesses  and  development  of  the  eoneeptual  model  keeping  efforts  within  the  seope  of 
Domain  Analysis. 

Benefits  of  IDEF3  Methodology 

Some  benefits  of  the  IDEF3  methodology  are  realized  through  its  ability  to 
identify  obseure  proeess  links,  highlight  redundant  and/or  non-value-added  aetivities,  and 
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speed  the  design  of  new  proeesses.  Some  of  the  benefits  realized  by  the  use  of  the  IDEF3 
methodology  are  listed  below. 

Capture  and  distribute  detailed  manufaeturing  proeess  knowledge  (e.g.,  Hubble 
teleseope  mirror  fabrieation  proeess)  among  geographieally  dispersed  units. 

Determine  the  impaet  of  an  organization’s  information  resouree  on  the  major 
operating  seenarios  of  an  enterprise. 

Provide  an  implementation-independent  speeifieation  for  human  system 
interaetion. 

Define  data  eonfiguration  management  and  ehange  eontrol  poliey. 

Doeument  the  deeision  proeedures  affeeting  the  states  and  life  cyele  of  eritieal 
shared  data. 

Speed  the  development  of  high  quality  IDEF  funetion  models. 

Speed  the  development  and  validation  of  simulation  models. 

Develop  real-time  eontrol  software  by  providing  a  meehanism  to  elearly  define 
faets,  deeision  points,  and  job  elassifioations. 

Define  the  behavior  of  workflow  management  systems  and  applieations. 

Preseribe  the  proeess  by  whieh  ehange  within  an  organization  will  be  aehieved. 

IDEF3  is  useful  in  both  eapturing  the  system  deseription  and  in  model 

development  (Belhe  and  Kusiak  1995).  A  well  developed  deseription  and  eoneeptual 

model  will  be  very  useful  in  the  reuse  of  model  eomponents.  Additionally,  IDEF3  allows 

for  the  eapture  of  alternative  views  or  deseriptions  enhaneing  the  understanding  of  the 

system  and  the  usefulness  of  the  model.  Mayer  et.  al.  explained, 

“When  eompared  to  model  building,  deseription  eapture  is  attraetive  as  a 
strategy  for  knowledge  aequisition  for  several  reasons.  First,  praetitioners 
generally  require  less  training  to  produee  deseriptions,  rather  than  models, 
of  their  domains.  Seeond,  a  model  deseription  of  a  given  situation  ean 
easily  be  reused  for  a  variety  of  purposes,  ineluding  model  building  (e.g., 
funetion  models,  simulation  models).  IDEF3  is  a  deseription  organizing 
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and  capture  method  that  directly  addresses  these  needs”  (Mayer,  Menzel  et 
al.  1995). 


IDEF3  Components/Elements 

IDEF3  methodology  has  four  major  components.  Boxes  or  UOBs  are  used  for 
proeesses,  arrows  or  links  to  represent  precedence  or  relationship,  junctions  are  used  to 
add  logic  to  the  diagram,  and  cireles  are  used  when  focusing  on  ontological  descriptions 
to  represent  object  states.  Additional  symbols  include  referents  and  notes.  The  IDEF3 
schematic  serves  to  detail  the  simulation  coneept.  The  mission  space  eontains  the  process 
elements  and  is  comprised  mostly  of  the  sehematics.  The  simulation  space  and  the 
simulation  context  are  addressed  by  elaborations,  notes,  and  referents  that  will  be 
discussed  later.  The  following  figures  provide  an  example  of  the  two  types  of  diagrams 
developed  through  the  IDEF3  methodology. 

Figure  7  provides  a  simple  view  of  the  proeess-oriented  perspective.  Within  this 
diagram  are  several  processes  linked  together  showing  the  order  of  precedence. 

Although  this  diagram  is  simple  in  nature,  it  eontains  the  all  the  key  eomponents  of  a 
IDEF3  schematie.  Additional  information  and  documentation  can  be  added  as  necessary 
and  will  be  diseussed  later  in  this  ehapter. 


Figure  7.  Sample  IDEF3  Process  Diagram 

(Mayer,  Menzel  et  al.  1995) 
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Figure  8  provides  an  example  of  how  IDEF3  can  be  used  to  produce  an  object- 


oriented  diagram.  In  this  view,  an  object  and  its  current  physical  state  are  represented  by 


the  circles  with  the  processes  acting  upon  the  object  coming  in  perpendicularly.  This 


viewpoint  can  be  used  to  follow  and  object  through  various  processes  detailing  the 


current  status  of  that  object. 


Figure  8,  Sample  IDEF3  State  Diagram 

(Mayer,  Menzel  et  al.  1995) 

Both  the  previous  examples  utilized  the  most  common  symbols;  however,  there 
are  more  symbols  that  help  to  make  the  IDEF3  methodology  more  useful.  The  basic 
elements  used  to  develop  an  IDEE3  description  are  contained  in  Eigure  9. 

UOBs  are  used  to  describe  what  happens  in  general  within  the  system  and  not 
necessarily  what  happened  at  a  particular  time.  It  represents  an  activity  that  happens 
repeatedly  over  time.  In  the  case  of  a  process,  the  description  represents  types  of 
situations  that  can  occur  in  the  system  and  the  logical  and  temporal  constraints  that  bind 
them  together  (Mayer,  Menzel  et  al.  1995). 
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Process  Schematic  Symbols 


Object  Schematic  Symbols 
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Figure  9,  IDEF3  Methodology  Schematic  Symbols 

(Mayer,  Menzel  et  al.  1995) 

Links  are  used  to  eonneet  symbols  ereating  the  dynamie  proeess  representation. 
Primarily  used  to  denote  relationships,  links  generally  inelude  express  temporal,  logieal, 
causal,  natural,  and  conventional.  The  most  common  use  is  for  temporal  precedence 
represented  by  a  solid  black  line  with  an  arrow  point  on  one  end.  Additionally,  there  are 
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four  types  of  constrained  precedence  links.  They  are  represented  by  a  directional  triangle 
on  the  line,  a  double  triangle  allowing  for  both  directions,  and  a  square  representing  a 
general  constraint.  Lastly,  dashed  links  are  not  predefined  and  are  therefore  usually  user 
defined  (Mayer,  Menzel  et  al.  1995). 

Junctions  provide  for  the  ability  of  expressing  the  logic  of  process  branching 
while  simplifying  temporal  sequencing  relationships  between  processes.  There  are  four 
types  of  junctions. 

Points  at  which  a  process  diverges  into  multiple  parallel  subprocesses; 

Points  at  which  a  process  diverges  into  multiple  (possibly  nonexclusive) 
alternative  subprocesses; 

Points  at  which  multiple  parallel  subprocesses  converge  into  a  single  “thread;” 
and 

Points  at  which  multiple  alternative  subprocesses  in  the  process  converge  into  a 
single  thread. 

The  four  types  of  junctions  represent  the  four  sorts  of  branch  points.  The  first  two 
represent  the  fan-out  type  while  the  remaining  two  are  for  fan-in  type  branches. 
Conjunctive  branches  are  used  with  multiple  parallel  processes  while  disjunctive 
branches  are  used  with  multiple  alternative  subprocesses.  Conjunctive  branches  are 
represented  by  the  symbol  “&.”  Disjunctive  branches  can  be  either  inclusive  or  exclusive 
represented  by  “OR”  and  “XOR”  respectively  (Mayer,  Menzel  et  al.  1995). 
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Table  4,  IDEF3  Junction  Types 


Junction  Type 

Fogic 

Synchronization  Type 

Description 

Fan-in 

AND 

Asynchronous 

All  preceding  processes  must  be 
completed  before  preceding 
forward. 

OR 

One  or  more  of  the  preceding 
processes  will  complete. 

AND 

Synchronous 

All  preceding  processes  will 
complete  simultaneously. 

OR 

One  or  more  of  the  preceding 
processes  will  complete 
simultaneously. 

XOR 

Exactly  one  of  the  preceding 
processes  will  complete. 

Fan-out 

AND 

Asynchronous 

All  following  process  must 
start. 

OR 

One  or  more  of  the  following 
processes  will  start. 

AND 

Synchronous 

All  following  processes  will 
start. 

OR 

One  or  more  of  the  following 
processes  will  start 
simultaneously. 

XOR 

Exactly  one  of  the  following 
processes  will  start. 

(adapted  from  (Vernadat  1996) 

To  further  enhance  the  ability  of  the  1DEF3  methodology  for  process  description, 
decompositions  are  added  to  give  greater  detail  and  insight  into  the  system. 
Decompositions  are  used  to  generate  a  hierarchical  view  of  the  process  showing  the 
subprocesses  contained  within  a  single  UOB.  By  enabling  this  “drill-down”  or  exploded 
viewpoint  capability,  it  is  possible  to  view  the  process  at  various  levels  of  detail 
depending  on  the  information  desired. 
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Additionally,  various  types  of  information  can  be  attached  to  a  process.  This 
information  includes  elaborations,  properties,  simulation  info,  attachments, 
decompositions,  notes,  and  sources.  As  they  appear  in  ProSim  7.0  from  KBSI,  an 
Elaboration  block  is  used  to  provide  information  about  objects,  facts,  and  constraints. 

The  types  of  properties  added  are  integer,  real,  string.  Boolean,  or  user  defined.  With 
each  property  is  stored  its  value,  a  description,  notes,  and  source  information.  If  needed, 
simulation  data  can  be  entered  and  stored.  Attachments  can  be  inserted  to  provide 
additional  information  including  data  files,  pictures,  or  text.  A  list  of  decompositions  and 
access  to  information  regarding  each  is  accessible  at  this  point;  each  decomposition  can 
contain  any  of  the  symbols  available  representing  some  subsystem  within  the  whole 
process.  Lastly,  notes  may  be  added  to  give  further  explanation  and  sources  of 
information  may  be  recorded  to  allow  others  to  return  to  the  source  for  further 
explanation. 

Like  the  Elaboration  block  in  a  process  diagram,  there  is  an  additional  block  in 

the  object-centered  view:  Referent.  Referents  enhance  understanding  and  simplify  the 

construction  of  descriptions.  Referents  are  generally  used  to  accomplish  three  functions. 

Refer  to  a  previously  defined  UOB  without  duplication  of  its  definition  to  indicate 
that  another  instance  of  a  previously  defined  UOB  occurs  at  a  specific  point  in  the 
process  (without  loopback). 

Transfer  control  or  indicate  a  loopback  in  the  processing. 

Lorm  references  or  links  between  the  process  schematics  and  object  schematics. 
There  are  two  types  of  referents:  Call-and-Continue  Referent  and  Call-and-Wait 
Referent.  The  Call-and-Continue  type  is  the  most  common  used  referent  and  represents  a 
situation  where  the  referenced  element  needs  to  be  initiated  and  then  the  processes  can 
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continue.  The  Call-and-Wait  type  represents  the  situation  where  situation  where  the 
proeess  continues  after  the  referenced  element  has  completed  its  processing.  The 
following  table  eontains  the  various  referent  symbol  structures. 


Table  5:  Referent  Symbol  Structure 


Referent  Type 

Referenced  EIcnient 

Label 

Locator 

IJOB 

IJOB  l.abcl 

I'OB# 

SCENARIO 

Scenario  Label 

Scenario  # 

rs 

Transition  Schematic 

Label 

Transition  Schematic  # 

tiO-TO  (used  only  in 
process  .schematics) 

I'OB  Label 

lJOB#/Scenario  #  or 
Decomposition  #  in  which  the 
ID  occurs 

Scenario  Label 

Scenario  # 

.lunction  Type  (i.e..  &.  O. 
orXOR) 

.lunction  #/Scenario  #  or 
Decomposition  #  in  which  the 
ID  occurs 

(Mayer,  Menzel  et  al.  1995) 


IDEF3  Development 

Coehran  and  Wheaton  suggest  that  development  of  a  IDEF3  model  begin  with  a 

simple  context  model,  be  supplemented  with  an  aetivity  model  containing  discrete 

elements,  and  then  add  a  hierarchieal  breakdown  view  of  activities  (Cochran  and 

Wheaton  2002).  When  developing  IDEF3  descriptions,  the  following  evolutionary  cyele 

ean  be  used  to  capture  the  knowledge  about  aetivities  and  processes. 

Collect:  Acquire  observations  and  written  deseriptions  of  both  proeess 
instantiations  and  generalizations  aeross  proeess  instantiations. 

Classify:  Individuate  situation  types,  objects,  object  types,  object  states,  and 
relations. 

Organize:  Assemble  the  data  that  has  been  colleeted  and  elassified  using  IDEF3 
structures 
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Validate:  Ensure  that  the  statements  made  in  IDEF3  are  grammatically  correct 
and  that  they  corroborate  with  the  collected  descriptions  of  the  actual  or  idealized 
situation. 

Refine:  Make  adjustments  to  the  existing  structures  to  incorporate  newly 
discovered  information,  to  simplify  the  presentation,  or  to  highlight  important 
elements  interest  (Mayer,  Menzel  et  al.  1995). 

Using  these  steps  and  a  combination  of  the  conceptual  model  building  steps  suggested  by 

Benjamin  et  al  and  Pace  should  enable  the  model  developer  to  gain  a  greater 

understanding  of  the  process  while  providing  the  appropriate  amount  of  detail  needed  for 

reuse  and  conversion  to  a  simulation  model. 

Conclusion 

Eor  this  research  effort,  data  concerning  the  processes  surrounding  space  shuttle 
ground  turnaround  operations  will  be  collected  and  used  to  generate  UOBs  with 
elaborations  and  other  descriptions  being  generated  as  needed.  The  data  will  come  from 
work  breakdown  structures,  process  diagrams,  tables  and  spreadsheets,  and  from  subject 
matter  experts.  The  data  will  be  organized  as  needed  and  then  organized  into  an  IDEF3 
structure  that  will  paint  the  picture  of  operations  at  KSC.  Once  the  IDEF3  model  has 
been  generated,  the  researchers  will  validate  the  model  based  on  the  data  collected  and 
descriptions  generated  ensuring  statements  made  are  grammatically  correct  and  that  they 
express  the  proper  view  of  the  actual  system.  If  any  new  information  is  uncovered  during 
this  process,  it  will  be  added  and  adjustments  will  be  made  while  the  model  is  kept  as 
simple  as  needed  and  contains  enough  detail  to  be  complete. 

Five  steps  will  be  used  to  conduct  the  data  analysis.  The  first  is  to  organize  the 
data  and  facts.  This  is  a  general  collection  and  organization.  The  next  step  is  to  identify 
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categories  for  organizing  data  and  facts  into  meaningful  groups.  The  third  step  is  to  give 
special  attention  to  speeific  items  requiring  examination  for  relevanee.  Next,  patterns  and 
groups  are  determined  based  on  a  logical  structure  for  the  model.  The  last  step  is  to 
proceed  with  model  development  (Leedy  and  Ormrod  2000). 

To  simplify  the  model  development  proeess  and  to  enable  the  completion  of  the 
above  steps,  a  simple  method  has  been  chosen  to  reduce  the  data  to  a  more  manageable 
and  meaningful  level.  Data  relating  to  procedures  seheduled  and  performed  on  the  space 
shuttle  on  a  regular  basis  will  be  ineluded.  Data  sueh  as  trouble  shooting  unexpected 
errors  or  malfunetions  and  modifications  will  be  removed  from  the  data  set.  Any 
subsequent  data  generated  as  a  result  of  these  proeedures  will  be  removed  as  well. 

Chapter  4  will  detail  this  process  and  how  it  was  conducted  with  the  actual  data  as  well  as 
present  the  various  eomponents  of  the  model. 

To  build  the  model,  the  system  will  need  to  be  divided  into  usable  and  meaningful 
groups.  Several  possibilities  exist  for  these  groupings.  First,  all  the  processes  within 
eaeh  structure  could  be  grouped  and  modeled.  Another  possible  method  would  be  to 
group  by  similar  structure  or  function — component  based.  In  this  model,  the  grouping 
would  be  by  system  or  sub-system  regardless  of  faeility.  Additionally,  the  groupings 
could  be  based  on  proeess  ID  or  proeedure  number.  This  would  allow  similar  aetivities 
to  be  grouped.  However,  eaeh  of  these  on  their  own  would  not  provide  a  proper 
description  or  dividing  point  for  data  analysis.  The  best  choice  is  a  combination  of  the 
three.  In  general,  activities  will  be  grouped  by  system  or  sub-system  with  proeedure 
numbers  and  process  IDs  being  used  to  help  make  this  division.  In  some  cases,  the 
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procedures  for  a  single  system  oecur  in  multiple  facilities;  therefore,  larger  more  complex 
proeedures  will  be  first  divided  by  system  and  then  subdivided  by  facility. 

By  focusing  on  systems  rather  than  some  other  grouping  method,  the  focus  is 
placed  on  the  entities  where  trade-offs  will  occur.  Also,  the  model  will  be  more 
adaptable  and  attuned  towards  reuse.  As  changes  are  needed  for  each  sub  component  of 
the  model,  only  that  seetion  will  require  action.  Additionally,  components  of  the  model 
will  be  ready  for  inclusion  or  exclusion  as  required  in  order  for  the  model  to  evaluate 
various  scenarios. 

In  the  end,  the  IDEF3  model  will  provide  the  necessary  data  for  the  simulation 
developers  to  understand  the  proeesses  involved  in  space  shuttle  turnaround  enabling 
them  to  analyze  the  system  further  for  the  development  of  a  generalized  simulation. 

Based  on  this  initial  understanding,  the  simulation  developer  will  be  able  to  prepare  for 
various  alternative  choices  and  analyses  needed  to  aid  in  system  development.  One  of 
the  main  advantages  to  be  gained  from  this  effort  is  an  understanding  of  process  flow, 
precedence,  and  relationships  in  the  form  of  IDEF3  sehematics  with  drill  down  capability 
on  processes  that  require  greater  detail. 
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IV.  Analysis  and  Results 


Overview 

This  chapter  will  answer  Investigative  Question  #  4  utilizing  the  methodology 
discussed  in  Chapter  3  (Question  #  3).  This  chapter  will  begin  with  the  scope  and 
limitations  of  this  analysis  will  be  discussed  followed  by  the  threats  to  validity.  The 
assumptions  made  in  laying  out  the  conceptual  model  will  be  discussed  in  addition  to  the 
analysis  of  the  data  followed  by  the  results.  The  results  will  be  in  the  form  of  a  more 
detailed  discussion  of  the  operations  at  KSC  as  laid  out  in  the  model  along  with 
appropriate  diagrams  with  the  full  model  being  included  in  Appendix  B. 

Scope  and  limitations 

The  scope  of  this  projeet  was  to  stay  within  the  Domain  Analysis  function  and 
was  therefore  limited  to  the  development  of  a  conceptual  model.  The  analysis  and 
subsequent  model  development  will  be  limited  by  the  data  available  from  KSC.  The 
model  developed  will  be  a  baseline  conceptual  model;  no  analysis  of  the  proeesses  will 
be  made. 

Threats  to  validity 

Researeher  bias  may  influence  data  examined  either  by  preconceived  ideas  on 
proeess  flow  or  by  leaving  out  data  that  was  felt  to  be  unimportant.  When  collecting  data 
from  an  individual,  the  interviewee  may  influence  the  analysis  by  answering  questions 
based  on  their  own  opinion  of  the  data  and/or  by  selectively  or  inadvertently  supplying  or 
not  supplying  data.  The  data  eollected  is  primarily  dependent  upon  the  resources 


44 


available  at  KSC.  If  the  data  is  not  available  or  laeking,  the  model  will  either  be 
inaeeurate  or  insuffieient  in  the  area  of  eoneern.  Additionally,  the  sponsor  may  influenee 
the  direetion  of  research  effort  based  upon  their  own  preconceived  ideas. 

Assumptions 

The  selected  assumptions  may  influence  data  examined,  responses  from  the  interviewee, 
interpretation  of  observed  operations,  and  data  selection.  Selection  of  model  components 
may  affect  the  usefulness  and  generalizability  of  the  model.  The  following  assumptions 
were  used  when  analyzing  the  data  and  building  the  model: 

Unscheduled  maintenance  and  troubleshooting  is  not  relevant  to  the  development 
of  this  baseline  model.  This  data  represents  activities  not  performed  on  a  regular 
basis. 

Data  analysis 

The  basis  for  the  data  analysis  is  a  contextual  analysis.  The  data  was  examined 
for  activities  that  represented  the  general  flow  of  operations  at  KSC  for  the  turnaround  of 
the  space  shuttle  and  its  components  in  preparation  for  the  next  launch.  These  operations 
included  those  for  processing  the  orbiter  and  its  major  subsystems,  the  solid  rocket 
boosters  (SRB),  the  external  tank  (ET),  and  the  mobile  launch  pad  (MLP).  The 
processing  of  the  orbiter  comprises  the  greatest  amount  of  time  and  effort.  Because  of  its 
size,  this  activity  required  decomposition  for  greater  analysis  and  understanding. 

The  breakdown  of  orbiter  processing  was  driven  by  its  size  and  complexity  and 
one  additional  factor:  reusability.  In  order  for  this  model  to  be  useful  in  examining  other 
vehicles  and  conducting  trade-off  analysis  when  coded  as  a  simulation,  the  data  was 
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divided  into  groups  allowing  for  the  ereation  of  modules.  These  modules  eould  then  be 
included  or  excluded  as  necessary  for  varying  vehicle  types.  For  example,  a  new  type  of 
TPS  might  be  developed  that  does  not  require  the  use  of  tiles.  Therefore,  the  tile 
manufacturing  module  would  no  longer  be  necessary. 

To  analyze  the  data,  a  three  step  process  was  used  modeled  after  the  first  four  of 
Leedy’s  five  steps  in  Chapter  3.  The  first  step  was  to  organize  and  collect  the  data.  Next, 
areas  requiring  special  attention  for  examination  need  to  be  identified  examining  the  data 
for  relevance.  The  third  step  is  to  group  the  data  into  categories  looking  for  patterns  and 
logical  structure. 

Organize  and  collect  the  data 

The  data  used  in  this  analysis  came  from  several  sources  and  in  several  different 
formats.  The  formats  of  the  data  were  as  follows: 

Spreadsheets 
Tables 
Flowcharts 
Gantt  Charts 
Presentations 
Pictures 
Diagrams 
Reports  (textual) 

This  data  provided  names  of  various  processes  and  subprocesses  in  addition  to  start  and 
stop  times.  It  provided  descriptions  of  flows  and  sample  high  level  diagrams  that  were  in 
some  cases  the  only  source  of  data  for  analysis.  Also,  there  were  pictures  and 
descriptions  of  facilities.  Some  sources  provided  detailed  descriptions  of  various  systems 
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and  components.  Other  sources  provided  high  level  scheduling  data  while  others 
provided  detailed  proeessing  data  down  to  the  individual  task  performed. 

Some  of  the  data  was  focused  on  Space  Transportation  System  (STS)-81,  which  is 
considered  the  baseline  minimum  seheduled  time.  Other  data  sources  were  from 
eombined  mission  data  for  post-Challenger  missions.  The  pre-challenger  missions  were 
considered  to  be  too  dissimilar  to  those  following  that  they  were  not  included. 
Additionally,  STS-1 14  was  included  at  a  higher  level  of  detail  as  a  comparison  to  STS-81 
along  with  a  generalized  sehedule. 

Identify  categories 

What  was  discovered  is  that  the  same  general  proeedures  are  completed  on  each 
mission  especially  those  concerning  major  systems  that  are  of  greatest  interest.  The 
differing  data  sources  provided  varying  levels  of  detail  from  system  to  system,  but  when 
combined  provided  a  clearer  picture  of  proeedures  throughout  the  whole  ground 
turnaround  proeess.  Some  influenee  in  this  matter  eame  from  the  sponsor’s  focus  on  TPS 
and  propulsion  systems. 

The  area  containing  the  greatest  amount  of  information  was  the  data  sources 
concerning  the  space  shuttle  main  engines  (SSME)  and  the  thermal  protection  system 
(TPS).  These  two  areas  are  eonsidered  the  most  important  for  trade-off  analysis  and  have 
been  the  focus  by  both  NASA  and  AFRLWA.  Therefore,  the  initial  emphasis  was  placed 
on  these  two  systems.  Other  areas  were  added  as  data  and  time  permitted  with  the  intent 
of  produeing  the  most  comprehensive  and  complete  model  possible. 

Group  the  data 

When  examining  the  data,  some  sources  contained  extraneous  data  needing  to  be 
filtered  out  to  enable  a  clearer  view  of  the  pertinent  data.  Some  of  this  data  eoncerned 
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non-maintenance  activities  and  were  thus  not  part  of  the  ground  operations;  some  of  the 
data  was  for  operations  not  performed  at  KSC;  and  some  concerned  unscheduled 
maintenance.  Additionally,  data  concerning  modifications  and  upgrades  was  not 
included  in  the  model.  Any  data  not  scheduled  or  out  of  the  scope  of  this  research  was 
removed  from  the  data  set  and  was  not  considered  in  this  effort. 

Results:  Baseline  Conceptual  Model 

This  section  will  detail  the  model  as  developed  beginning  with  the  highest  level 
and  then  presenting  each  decomposition  as  necessary  to  clarify  the  major  components  of 
the  model.  Diagrams  from  the  model  will  be  provided  as  needed  while  the  whole  model 
will  be  available  in  Appendix  B. 

Overarching 

KSC  is  responsible  for  launch  operations,  landing  and  recovery  procedures,  and 
ground  turnaround  for  all  equatorial  orbits.  The  ground  operations  at  KSC  required  to 
turnaround  the  space  shuttle  being  considered  are  those  from  launch  to  launch  but  not 
including  any  mission  elements.  Launch  to  launch  is  considered  since  some  of  the 
activities  considered  begin  soon  after  launch — such  as  SRB  retrieval  and  MLP 
refurbishment,  which  begin  soon  after  launch.  The  major  activities  take  place  in  several 
different  facilities  located  relatively  close  to  each  other  with  the  exception  of  hazardous 
functions  being  geographically  separate. 

The  shuttle  industrial  complex  is  composed  of  many  buildings  utilized  in  the 
processing  of  STS  components  and  systems.  Some  of  the  facilities  are  left  over  from  the 
APOLLO  space  program  and  some  are  new  structures  built  specifically  for  the  shuttle 
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program.  Additionally,  there  are  faeilities  in  other  areas  that  support  the  shuttle  mission. 
The  faeilities  eonsidered  in  this  effort  are  the  hypergol  maintenanee  and  eheekout  faeility 
(HMF),  TPS  faeility,  OFF,  vehiele  assembly  building  (VAB),  MLP  refurbishment 
faeility,  and  launeh  pad.  Within  some  of  these  faeilities  may  exist  multiple  struetures  and 
bays.  The  details  of  these  faeilities  will  be  diseussed  along  with  the  operations  are 
eonducted  within  that  faeility.  Figure  10  provides  the  sehematie  for  this  sehematie. 


Figure  10.  Overarching  Diagram 
1.0  Landing  Prep/Recovery  Operations 

This  module  discusses  the  operations  conducted  beginning  when  the  landing  is  in 
preparation  and  when  the  orbiter  actually  touches  down.  Prior  to  landing,  vehicles, 
equipment,  and  personnel  are  made  ready.  Additionally,  the  weather  is  checked  to  ensure 
all  things  are  go  for  a  landing  at  KSC.  NASA  does  have  three  other  locations  for  landing 
if  the  weather  is  not  good  at  KSC  and  time  is  short  (not  modeled  in  this  effort).  Once  the 
decision  is  made  to  land  at  KSC,  vehicles,  equipment,  and  personnel  take  their  positions 
and  converge  on  the  orbiter  once  it  comes  to  a  stop.  Before  the  crew  may  exit  the  orbiter 


49 


and  maintenance  personnel  may  approach,  a  toxic  vapor  test  is  conducted.  Once  the  area 
is  declared  safe,  the  crew  exits,  time  critical  payloads  are  removed,  some  systems  are 
purged,  a  walk  down  inspection  of  the  TPS  is  made,  and  the  tires  are  inspected.  Figure 
1 1  provides  the  schematic  for  this  decomposition. 


Figure  11.  Landing  Prep/Recovery  Operations 


2.0  Post  Flight  Ground  Handling 

This  module  concerns  the  operations  necessary  to  transport  the  orbiter  from  the 
runway  to  the  OPF.  Once  on  the  ground  the  orbiter  has  no  means  of  propelling  itself;  the 
orbiter  free  falls  and  then  glides  to  a  landing  having  no  powered  flight  on  re-entry.  When 
ready,  the  orbiter  is  then  towed  to  the  OPF  for  processing. 


Figure  12,  Post  Flight  Ground  Handling 
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3.0  Orbiter  Processing 

This  is  the  single  largest  module  containing  several  decompositions  with  some 
having  multiple  decompositions  of  their  own.  The  dividing  of  data  and  creation  of 
modules  for  the  model  was  in  part  driven  by  divisions  present  in  the  data  form  KSC. 
KSC  tended  to  look  at  systems  and  divide  the  actions  on  those  systems  by  facility. 
Therefore,  this  research  effort  took  advantage  of  the  inherent  divisions  within  the  data. 

Before  diving  into  the  model,  a  brief  overview  of  the  major  facilities  involved 
with  this  section  is  required.  A  description  of  the  OFF  and  the  HMF  will  be  provided 
followed  by  a  description  of  the  orbiter  processing  decomposition.  Figure  12  provides 
the  schematic  for  this  level  of  decomposition. 

OPF 

Within  the  OPF  are  three  bays.  Since  there  are  three  orbiters  in  the  inventory, 
physical  capacity  is  not  a  problem.  Operations  considered  for  the  OPF  are  those  that 
begin  at  OPF  roll-in  and  end  at  rollout  but  do  not  include  concurrent  operations  in  other 
facilities.  For  example,  the  SSME  are  removed  and  sent  to  the  orbiter  main  engine 
maintenance  facility  (OMEMF)  and  are  either  returned  or  replaced  with  already 
refurbished  engines.  The  operations  in  the  OMEMF  will  be  dealt  with  separately.  The 
main  activities  in  the  OPF  considered  for  modeling  by  NASA  have  been  broken  down  to 
three  areas. 

External  surface  preparation  to  include  the  TPS. 

Payload,  midbody,  and  crew  compartment  work. 

Propulsion  system  especially  around  the  main  engine  compartment. 

Not  mentioned  above  are  many  other  important  tasks  that  must  be  integrated 
into  the  flow  such  as:  safing  the  forward  reaction  control  system  (FRCS), 
changing  the  tires;  polishing  the  windows;  trouble-shooting  the  previous 
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mission’s  in-flight  problems  and  a  host  of  minor  problems  that  oeeur  during 
the  eourse  of  any  OPF  flow;  and  performing  approved  modifieations  (Cates 
2003) 

For  the  OPF,  the  orbiter  is  rolled  in,  jaeked  up,  and  remains  in  plaee  until  it  is  time  to 
lower  it  down  and  send  it  to  the  VAB.  Personnel,  tools,  and  test  equipment  eome  to  the 
orbiter.  Some  eomponents  are  removed  and  maintenanee  is  performed  in  other  loeations. 
When  servieing  is  eomplete,  those  components  are  returned  and  reinstalled.  OPF 
processing  takes  approximately  80  days  to  complete. 

HMF 

The  HMF  is  one  facility  where  components  may  be  removed  and  taken  to  for 
further  maintenance  and  is  located  approximately  8  miles  from  the  main  complex  due  to 
hazardous  materials  (hypergolic  fuels)  handling.  This  facility  is  used  to  process  reaction 
control  system  (RCS)  components,  orbital  maneuvering  system  (OMS)  pods,  and 
auxiliary  power  units  (APU).  The  HMF  consists  of  three  buildings  which  contain  test 
cells  for  the  OMS  pods  and  FRCS,  storage  for  the  OMS  pods  and  FRCS,  and 
maintenance/servicing  centers  for  the  APUs.  Building  M7-961  contains  two  test  cells 
each  one  for  either  the  left  or  the  right  OMS  pod.  Building  M7-1212  contains  two  bays 
as  well.  One  bay  is  for  FRCS  processing  and  the  other  is  not  functional.  The  latter  bay  is 
used  for  storing  one  OMS  pod  or  one  FRCS. 
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Figure  13.  Orbiter  Processing 


3.1  ECS,  Crew  Module,  GNC,  Life  Support,  &  Comm 

Development  of  the  ECS,  Crew,  GNC,  Life  support  &  Comm  module  was  based 
upon  data  doeumented  in  the  OPF_dB_STS81_LbrClrs  exeel  spreadsheet.  The  initial 
239  lines  of  data  were  initially  redueed  by  approximately  thirty  pereent  by  removing  lines 
of  data  designated  as  “unplanned  troubleshooting  and  repair”.  The  remaining  167  lines 
of  data  were  broken  down  by  five  “design  diseiples”  for  model  development  ineluding; 

Command,  Control,  &  Health  Management 

Guidanee,  Navigation  and  Control  (GNC) 

Coekpit  &  Crew  Panel 

Environmental  Control  &  Life  Support  System  (ECLSS) 

Communications  (COMM) 

Though  start  and  finish  data  was  provided,  it  was  unclear  if  this  resulted  from  a  physical 
or  resource  constraint.  Therefore,  unless  obvious  precedence  was  observed  (i.e.,  removal 
before  installation),  tasks  are  modeled  in  parallel. 

Command,  Control,  &  Health  Management  subsystem  includes  the  computer 
processors  (DPS)  and  multifunction  electronic  display  (MEDS)  as  well  as  orbiter 
instrumentation.  The  GNC  system  utilizes  the  four  of  the  DPS  computers  during  critical 
flight  control  phases  of  the  mission.  Recycling  tasks  within  these  modules  are  non- 
hazardous  in  nature  and  include  checkouts  of  the  DPS  complex,  MEDS,  flight  recorder, 
master  timing  unit,  and  other  instrumentation  systems. 

Cockpit  &  Crew  Panel  and  the  ECLSS  include  inspection  and  maintenance  of  the 
cabin  air  conditioning/recirculation  and  flight-crew  systems.  The  ECLSS  system  is 
critical  to  the  atmospheric  conditions  within  the  crew  station.  Of  primary  importance  is 
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the  control  of  temperature  and  pressures  required  not  only  for  survival  of  the  crew,  but 
also  critical  electronics.  Tasks  within  this  module  are  non-hazardous  and  the  inspection 
and  maintenance  of  the  cabin  air  recirculation  system  require  orbiter  power  down 
conditions. 

The  communication  system  includes  the  microwave  scanning  beam  landing 
system,  the  KU  band  antenna  (located  in  the  payload  bay),  the  tactical  air  command  & 
navigation  system,  GPS  antenna,  close  circuit  television,  among  other  systems. 
Inspection  and  testing  tasks  within  this  module  are  non-hazardous. 
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Figure  14,  ECS,  Crew  Module,  GNC,  Life  Support,  &  Comm 

3.2  Ground  Systems  and  Facilities 

Within  this  module,  the  orbiter  is  connected  to  various  ground  systems  providing 
power,  cooling,  and  other  services  shutdown  when  the  internal  systems  were  deactivated. 
In  addition,  the  orbiter  is  jacked  up  off  its  landing  gear  and  suspend.  Next,  ground  access 
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systems  are  put  into  plaee  allowing  aceess  to  all  parts  of  the  orbiter  from  top  to  bottom. 
These  systems  ean  be  moved  and  adjusted  to  gain  aeeess  to  various  parts  of  the  orbiter 


without  obstructing  other  procedures. 


Figure  14,  Ground  Systems  and  Facilities 


3.3  Payload  Ops 

Though  data  was  available  in  the  OPF_dB_STS81_LbrClrs  excel  spreadsheet,  it 
was  unclear  which  data  was  generic  payload  bay  preparations  versus  specific  mission 
payload  tasks.  As  a  result,  development  of  the  Payload  Accommodations  module  was 
based  upon  data  documented  in  the  STS-81/OV-104  OPF  Assembly  Summary  Gantt 
charts.  Though  start  and  finish  data  was  provided,  it  was  unclear  if  this  resulted  from  a 
physical  or  resource  constraints.  Therefore,  unless  obvious  precedence  is  observed  or 
milestones  provided,  tasks  were  modeled  in  parallel. 
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The  payload  bay  area  eontains  four  eritieal  systems;  orbital  doeking  system, 
radiator  system,  and  fuels  eells,  and  the  erew  equipment  interfaee  system.  The 
eoneeptual  model  initiates  parallel  funetional/meehanieal  testing  verifieation,  and 
eloseout  of  these  systems.  Following  eloseout  of  the  individual  systems,  the  payload  bay 
undergoes  a  final  eleaning,  eloseout  and  the  function  of  hatch  is  verified. 
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Figure  15,  Payload  Accommodations 


3.4  Power  Management 

Development  of  the  Power  Management  module  was  based  upon  data  documented  in  the 
OPF_dB_STS81_LbrClrs  excel  spreadsheet.  The  initial  324  lines  of  data  were  initially 
reduced  by  approximately  forty-two  percent  by  removing  lines  of  data  designated  as 
“unplanned  troubleshooting  and  repair”.  The  remaining  187  lines  of  data  were  broken 
down  by  six  subsystems  for  model  development  including: 

-  APU 

Electric  Power  Distribution 
Fuel  Cell  Systems  (FCP) 

Hydraulic  Systems 
Orbiter  Electrical 

Orb  iter  Test  Conductor  Operations 

Though  start  and  finish  data  was  provided,  it  was  unclear  if  this  resulted  from  a  physical 
or  resource  constraint.  Therefore,  unless  obvious  precedence  is  observed,  tasks  were 
modeled  in  parallel. 

The  APU  is  a  hydrazine  fueled  system  that  provides  pressure  for  the  hydraulic 
system.  Hydrazine,  a  toxic  liquid,  requires  special  handling  during  the  recycling  process. 
Toxic  vapor  checks  are  required  to  determine  if  repair  is  required.  This  system  is 
inspected  at  the  OPF;  however,  the  repair  is  accomplished  at  the  HMF.  Following  repair, 
the  APU  system  is  returned  to  the  OPF  for  installation  and  leak  functional  testing. 

The  FCP  system  generates  power  for  the  orbital  electrical  system.  The  activities 
within  this  part  of  the  module  include  testing  the  power  reactant  storage  and  distribution 
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system  (stores  and  distributes  oxygen  &  hydrogen  reaetants  to  fuel  cells)  and  servicing  of 
the  waste  spray  boiler  (WSB)  used  to  cool  the  APU  system. 

The  recycling  of  the  hydraulic  systems  begins  with  the  inspection  of  the  hydraulic 
system,  including  the  checkout  and  servicing  of  the  WSB  used  to  cool  the  hydraulic 
system.  Following  servicing  of  the  hydraulic  system,  the  system  is  powered  up  for  the 
functional  checkout  of  the  circulation  pumps,  flight  control  system,  SSME,  OMS,  nose 
landing  gear,  and  hydraulic  brake  systems. 
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Figure  15,  Power  Management 


3,5  Propulsion 

Development  of  the  Propulsion  module  was  based  primarily  upon  data  doeumented  in  the 
OPF_dB_STS81_LbrClrs  exeel  spreadsheet.  The  initial  230  lines  of  data  were  initially 
redueed  by  approximately  thirty-three  pereent  by  removing  lines  of  data  designated  as 
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“unplanned  troubleshooting  and  repair.”  The  remaining  165  lines  of  data  were  broken 
down  by  five  subsystems  for  model  development  including: 

Shuttle  Main  Engines  (SME) 

Ground  Support  Equipment 
-  QMS 

Main  Propulsion  System  (MPS) 

Nondestructive  Evaluation 

Though  start  and  finish  data  was  provided,  it  was  unclear  if  this  resulted  from  a  physical 
or  resource  constraint.  Therefore,  unless  obvious  precedence  is  observed,  tasks  were 
modeled  in  parallel.  The  exception  to  this  analysis  methodology  was  the  SME  module 
which  was  based  upon  the  data  provided  in  a  NASA  Report  (Christenson  &  Komar  1998: 
50-59).  Data  provided  in  this  report  included  not  only  start  and  finish  data,  but  also 
precedences.  The  SME  must  be  removed,  inspected,  and  repaired  between  each  flight. 
Therefore,  the  conceptual  model  propulsion  model  is  broke  into  three  sections;  activities 
that  occur  from  OPE  roll-in  to  SME  removal,  engine  repair,  and  SME  installation  to  OPE 
roll-out. 

Eollowing  OPE  roll-in,  the  SME  is  dried  and  inspected,  the  heat  shield  removed, 
and  the  low  pressure  pump  torque  is  checked.  The  MPS  lines  are  checked,  protective 
covers  installed,  leak  and  function  tests  are  performed.  The  OMS  subsystem  is  safed, 
deserviced,  and  inspected.  Approximately  12%  of  these  inspections  result  in  a  need  for 
repair/servicing  of  the  OMS  pods.  Similarly,  38%  of  these  inspections  result  in  a  need 
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for  repair/serving  of  the  FRCS.  The  repair  of  the  OMS  and  FRCS  is  hazardous, 
therefore,  if  the  OMS  and  FRCS  require  repair,  they  are  sent  to  HMF. 


Once  the  SSMEs  are  removed,  they  are  taken  to  the  OMEMF  and  serviced. 


Eigure  16  provides  the  flow  at  this  level. 


Figure  16.  OMEMF 

In  the  event  that  a  new  engine  would  be  used,  the  process  flow  would  be  quite 
different  much  simpler  than  that  of  the  existing  engines.  Figure  17  provides  the 
schematic  for  this  level  of  decomposition. 
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Figure  17.  Existing  Engine 


When  a  replacement  engine  enters  the  OFF,  it  is  inspected  prior  to  installation. 
The  engine  is  installed  and  integrated  with  the  MPS.  SME/MPS  integration  is  tested,  the 
engine  and  dome  mounted  heat  shields  are  installed,  the  gimbal  clearance  is  checked,  and 
the  SME  inspected  prior  to  OPE  roll-out. 

3.6  Safety  Management  and  Control 

Development  of  the  Safety  Management  &  Control  module  was  based  primarily 
upon  data  documented  in  the  OPE_dB_STS81_EbrClrs  excel  spreadsheet.  The  sole 
subsystem  in  this  “design  discipline”  is  the  Purge,  Vent,  and  Duct  system.  This  system 
supports  systems  within  unpressurized  compartments  by: 
gas  purge  for  thermal  conditioning 

-  prevent  accumulation  of  hazardous  gases 

-  provide  venting  during  ascent  and  reentry, 
drain  trapped  fluids, 

condition  window  cavities  to  maintain  visibility. 
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3. 7  Structures,  Mechanisms,  and  Vehicle  Handling 
Development  of  the  Struetures,  Meehanisms,  and  Vehicle  Handling  module  was  based 

upon  data  documented  in  the  OPF_dB_STS81_LbrClrs  excel  spreadsheet.  The  initial 

405  lines  of  data  were  initially  reduced  by  approximately  twenty-four  percent  by 

removing  lines  of  data  designated  as  “unplanned  troubleshooting  and  repair”.  The 

remaining  309  lines  of  data  were  broken  down  by  nine  subsystems  for  model 

development  including: 

Ground  Support  Equipment 

Mechanism 

Nondestructive  Evaluation 
Orbiter  Handling  Equipment 
Eorward  Panel  Repair 
Pyrotechnic  Systems 
Quality  Engineering 
Orbiter  Structures 
-  VPE 

Though  start  and  finish  data  was  provided,  it  was  unclear  if  this  resulted  from  a 
physical  or  resource  constraint.  Therefore,  unless  obvious  precedence  is  observed,  tasks 
were  modeled  in  parallel. 

The  Mechanism  subsystem  includes  such  systems  as  the  orbiter  docking  system, 
main  landing  gear  assembly,  nose  landing  gear  assembly,  and  external  tank  door 
operations.  Each  of  these  systems  are  inspected,  and  checked  for  leaks  and  function. 

Eor  example,  the  orbiter  docking  system  was  initially  designed  to  dock  with  the  Russian 
Mir  space  station,  but  is  now  used  to  dock  with  the  International  Space  Station.  The 
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recycling  process  requires  an  inspection  of  the  vestibule  and  an  internal/external  post 
flight  inspection.  If  all  is  in  working  condition,  a  protective  cover  is  installed  and  the 
docking  mechanism  undergoes  a  functional  check. 

The  structure  of  the  orbiter  is  also  inspected,  repaired,  and  checked  out  as  part  of 
the  recycling  process.  Of  interest  in  this  area  are  the  windows  which  must  be  inspected, 
polished,  and  sometimes  removed  and  repaired.  A  vast  majority  of  the  “unplanned 
troubleshooting  and  repair”  noted  above  is  to  the  structure  of  the  orbiter. 
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Figure  18,  Structures,  Mechanisms,  and  Vehicle  Handling 


3.8  TPS  Processing 

There  are  several  forms  of  thermal  proteetion  on  the  orbiter.  These  items  are 
either  stored  after  delivery  or  manufactured  at  KSC.  The  most  time  consuming  part  of 
the  TPS  is  the  orbiter  tiles,  which  are  manufactured  individually  by  hand  or  by  machine. 
Each  tile  has  a  specific  place  on  the  orbiter  and  is  not  interchangeable.  Servicing  the  TPS 
on  the  orbiter  begins  with  a  walk  down  inspection  on  the  runway  after  landing.  Once  the 
orbiter  is  in  the  OPE,  the  inspection  of  the  TPS  begins  and  is  broken  into  various  hard  to 
define  groups.  The  inspection  and  maintenance  of  TPS  components  is  an  ongoing 
process  throughout  much  of  the  OPE  processing  time.  Therefore,  the  TPS  procedures 
were  not  modeled  moment  by  moment  but  rather  by  procedure  beginning  with  the 
inspections. 

There  are  eight  components  that  make  up  the  TPS  each  having  subcomponents 
with  various  levels  of  inspection  required.  The  main  components  of  the  TPS  are  as 
follows: 

-  Reusable  Surface  Insulation  (RSI)  Tiles 

-  Advanced  Elexible  Reusable  Surface  Insulation  (AERSI)  Blankets 

-  Pelt  Reusable  Surface  Insulation  (PRSI) 

-  Reinforced  Carbon-Carbon  (RCC) 

-  Gap  Pillers 

-  Thermal  Barriers 

-  Thermal  Seals 

-  Window  Thermal  Panes 

Depending  on  the  location  on  the  orbiter  and  the  type  of  material,  the  item  will  either 
receive  a  macro-level  or  micro-level  inspection.  The  macro-level  inspection  is 
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accomplished  at  a  distance  of  3  to  5  feet  and  is  a  visual  inspection  looking  for  major 
inspections.  In  some  cases,  the  macro-level  inspection  is  a  precursor  to  a  more  detailed 
miero-level  inspection  possibly  requiring  specialized  equipment  and  is  primarily  a  hands- 
on  inspection.  These  inspections  are  further  divided  by  10  areas  on  the  orbiter.  For  this 
model,  it  was  decided  to  group  the  inspeetions  by  these  10  areas  when  modeling  the 
inspections.  Since  the  inspections  can  occur  in  any  order  and  maintenance  may  begin 
before  ah  the  inspections  are  complete,  the  model  allows  for  the  inspections  and 
maintenance  activities  to  be  performed  in  parallel  as  seen  in  Figure  19. 


Figure  19,  TPS  Processing 
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Within  the  data  concerning  TPS  maintenance  falls  the  reworking  of  payload  bay 
door  (PLBD)  hinges  and  the  orbiter  drag  chute  used  during  landing  to  help  slow  the 
orbiter  down  so  the  breaks  may  be  used.  During  various  operations,  it  may  be  necessary 
to  install  protective  pads  on  the  wings  of  the  orbiter  so  this  task  is  modeled  in  parallel  to 
the  inspection  and  maintenance  activities  allowing  for  the  operation  to  occur  as  needed. 
Additionally,  the  RSI  tiles  and  FRSI  must  be  rewaterproofed  before  each  launch.  The 
waterproofing  process  makes  the  components  hygrophobic  (Gordon  1995).  This  process 
keeps  the  components  from  taking  on  water  and  increasing  weight  and  reduces  the 
possibility  of  damage.  Since  the  waterproofing  compound  is  hazardous,  the 
waterproofing  operations  are  generally  conducted  on  the  third  shift  when  no  one  else  is 
present.  Those  performing  the  waterproofing  operations  must  where  protective  suits. 

Much  of  the  TPS  is  manufactured  or  assembled  on  site  at  KSC  within  the  TPS 
Facility.  The  components  with  more  detailed  operations  were  modeled  with  more  detail 
while  others  were  included  with  only  a  description  rather  than  a  full  decomposition.  The 
most  detailed  operation  is  for  the  RSI  tiles  as  seen  in  Figure  20. 
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The  orbiter  contains  almost  20,000  RSI  tiles  of  which  96  on  average  require 
replacement  and  1,800  require  repair.  Tile  replacement  requires  the  greatest  amount  of 
time  for  TPS  maintenance  taking  up  to  60%  of  the  total  TPS  man-hours.  Inspections 
require  10%  of  the  time,  gap  filler  maintenance  uses  22%  of  the  time,  and  the  rest  is 
divided  among  the  other  components  (Livingston  and  Rooney  2003).  A  major  process 
that  eats  up  much  of  the  tile  replacement  time  is  tile  manufacturing.  It  is  clear  that  any 
new  system  using  a  different  TPS  system  could  potentially  reduce  processing  time 
considerably. 

Each  tile  is  unique  and  requires  machining  form  a  tile  blank  that  is  produced  on 
site  at  KSC.  The  tile  can  be  made  form  a  computer  file  or  from  a  physical  mockup  made 
from  the  space  it  was  removed  from.  In  some  cases,  the  physical  model  is  digitized  and 
manufactured  on  a  numerically  controlled  machine  the  same  as  those  using  a  computer 
file.  Although  the  model  allows  for  rework  after  pre-fit,  the  tiles  made  by  hand  require 
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more  time  and  generate  more  rework  and  serap  which  is  not  detailed  in  the  model.  Each 
of  the  two  pre-fits  is  conducted  by  taking  the  tile  to  the  OPE  and  fitting  it  on  the  orbiter. 
As  a  result  of  the  pre-fit  procedures,  the  TPS  Eacility  is  located  near  the  OPE  to  help 
reduce  the  time  needed  for  tile  replacement.  Eigure  21  contains  the  decomposition  for 
RSI  Tile  manufacturing. 
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Figure  21.  RSI  Tile  Manufacturing 

4. 0  Transport  Orbiter  from  OFF  to  VAB 

After  OPE  processing  is  complete  and  post  inspections  are  good,  the  orbiter  is 
transferred  to  the  VAB.  To  transfer  the  orbiter  to  the  VAB,  the  Orbiter  Transport  System 
is  used  rather  than  towing  the  orbiter  on  its  wheels;  the  orbiter’ s  landing  gear  is  closed 
and  sealed  until  extended  for  landing.  The  transportation  process  takes  approximately  1 
day  to  complete. 

5.0  VAB 

The  VAB  is  where  the  SRBs  are  assembled,  the  ET  is  stored  and  processed,  and 
the  shuttle  components  are  mated  to  each  other  on  top  of  the  MLP.  The  VAB  was 
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originally  built  to  support  the  Saturn  V  rocket  and  is  thus  a  very  large  facility  with  four 
bays.  Two  bays  are  used  for  mating  operations  the  other  two  contain  one  storage  and  one 
checkout  cell  each  for  ET  processing.  Additionally,  one  of  the  latter  bays  may  be  used 
for  temporary  protection  of  the  shuttle  assembly  from  inclement  weather — such  as  a 
hurricane.  The  VAB  is  designed  to  withstand  winds  up  to  125  MPH. 

The  mating  process  generally  involves  the  MLP  being  placed  in  one  of  two  bays. 
Then  the  SRBs  are  attached  to  the  MLP.  Next,  the  ET  is  mated  to  the  SRBs  but  not  to  the 
MLP;  the  SRBs  will  be  the  only  objects  mated  to  the  MLP  and  will  support  all  the 
weight.  The  last  major  operation  is  the  mating  of  the  orb  iter.  This  procedure  is  quite 
delicate  since  the  facility  was  not  designed  for  this  operation.  The  overhead  crane  system 
is  used  to  lift  the  orbiter  and  pass  it  at  just  the  right  angle  through  several  support 
structures  until  it  is  in  the  appropriate  bay.  Then  the  orbiter  is  put  into  its  place.  The 
mating  of  all  components  takes  approximately  1  week  to  complete.  Other  operations  in 
the  VAB  surround  the  processing  of  SRBs  and  ETs. 
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Although  final  SRB  assembly  occurs  in  the  VAB,  most  of  the  SRB  operations 
occur  in  the  nearby  Rotation,  Processing,  and  Surge  Facility  (RPSF).  The  RPSF  contains 
three  structures:  processing  facility,  support  building,  and  storage  building.  The 
processing  building  is  used  for  receiving,  inspecting,  segment  rotation,  and  aft  booster 
buildup.  The  storage  building  can  store  up  to  eight  segments  or  two  boosters.  The 
operations  within  the  RPSF  are  considered  hazardous  since  the  boosters  contain  live  solid 
rocket  fuel.  When  the  segments  are  ready,  they  are  transported  to  the  VAB  for  stacking 
as  previously  described. 


Figure  23,  SRB  Operations  in  the  RPSF 
6.0  Transport  Shuttle  to  Launch  Pad 

The  integrated  shuttle  including  orbiter,  SRBs,  and  FT  atop  the  MLP  are 
transported  to  the  launch  pad  mounted  to  one  of  the  crawler/transporters.  The  crawler 
transporter  is  driven  into  the  bay  containing  the  integrated  shuhle  and  is  lifted  until  the 
MLP  is  taken  off  its  supports.  The  entire  assembly  then  begins  the  8  hour  drive  to  one  of 
two  launch  pads.  The  crawler/transporter  follows  a  130  foot  wide  track  containing  two 
40  foot  wide  gravel  paths  separated  by  a  50  foot  median.  Once  at  the  launch  pad,  the 
crawler/transporter  lowers  itself  and  lets  the  MLP  rest  on  the  supports  at  the  launch  pad. 
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The  crawler/transporter  is  then  removed  to  a  safe  distanee  but  kept  nearby.  If  bad 
weather  is  expeeted,  the  shuttle  assembly  ean  be  taken  baek  to  an  open  bay  in  the  VAB 
for  protection. 

7. 0  Launch  Pad  Ops 

The  launch  pad  is  where  the  launch  takes  place,  final  testing  of  systems  occurs, 
vertical  and  hazardous  payloads  are  installed,  and  liquid  fuel  is  loaded  into  the  ET.  There 
are  two  launch  pads  used  for  the  shuttle.  The  launch  pads  are  approximately  3-4  miles 
from  the  VAB  and  are  on  the  coast  allowing  for  launches  to  take  place  over  the  water. 
This  allows  for  the  SRBs  to  be  dropped  into  and  later  recovered  from  the  ocean. 

Activities  that  are  hazardous  or  inherently  dangerous  are  held  off  until  the  last 
moment  they  can  occur.  The  launch  pad  is  where  many  of  these  operations  are 
conducted.  The  liquid  propellant  for  the  ET  is  pumped  in  and  the  hypergolic  fuel  for  the 
ERCS,  APU,  and  OMS  pods  uploaded.  Ordinance  devices  are  installed  and  activated  on 
the  launch  pad  to  limit  the  opportunity  for  premature  discharging. 

Additional  activities  include  the  inspection  of  connections  and  lines  to  include  the 
X-raying  of  the  SSME  hydraulic  quick  disconnects.  The  TPS  is  inspected  where  it  is 
adjacent  to  moving  components  and  on  doors  for  proper  seal.  The  ET  is  inspected  for  ice 
buildup  to  determine  any  potential  hazards  for  the  orbiter.  Also,  the  cryogenic  propellant 
lines  are  sprayed  to  prevent  ice  buildup.  Easily,  any  hazardous  or  vertically  integrated 
payload  is  loaded  into  the  payload  bay  while  the  shuttle  is  on  the  launch  pad.  Generally, 
satellites  are  vertically  integrated.  The  model  for  launch  pad  operations  can  be  seen  in 
Eigure  24. 
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Figure  24,  Launch  Pad  Operations 


MLP  refurbishment  facility 

The  MLP  is  refurbished  after  each  launch  and  is  reused.  This  MLP  goes  from  this 
facility  to  the  VAB  where  the  shuttle  assembly  is  mated  to  it  and  then  is  delivered  to  one 
of  the  launch  pads.  The  MLP  with  or  without  the  shuttle  assembly  is  transported  on  one 
of  two  crawler  transporters  which  are  another  left  over  item  from  the  APOLLO  space 
program. 

8. 0  SRB  Recovery 

The  SRBs  touchdown  within  minutes  after  launch.  However,  before  touchdown, 
the  first  set  of  parachutes  is  deployed  form  the  frustrum  to  slow  the  descent.  Then  the 
frustrum  is  separated  from  the  rest  of  the  SRB  and  the  main  chute  is  deployed.  The  SRB 
lands  in  the  water  vertically  and  stays  afloat  due  to  water  trapped  inside.  In  addition,  a 
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strobe  and  homing  beacon  are  used  to  aid  in  locating  each  SRB.  Each  frustrum  and 
parachute  is  retrieved  and  then  the  parachute  for  each  SRB.  The  SRBs  are  towed  back  to 
the  dock  where  they  are  taken  to  the  RPSF  for  processing.  After  processing,  the  SRBs 
are  shipped  via  rail  to  Utah  where  they  are  refurbished.  Since  there  are  two  ships 
available  for  recovery,  each  frustrum  and  SRB  pair  can  be  retrieved  in  parallel  as 
opposed  to  the  model  in  Figure  25. 


Figure  25,  SRB  Recovery  Operations 

Validation  and  Verification 

A  conceptual  model  is  the  “basis  for  judgment  about  a  simulation’s  capabilities  in 
conditions”  for  which  it  was  not  tested  (Pace  2000).  The  key  to  achieving  such 
compatibility  and  reliability  in  simulation  data  is  the  simulation  conceptual  model 
because  the  simulation  conceptual  model  is  the  basis  for  judgment  about  the 
appropriateness  (validity  evaluation)  of  simulation  data  for  all  conditions  not  specifically 
tested.  When  a  model  is  nearing  completion,  it  requires  analysis. 
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The  evaluation  eriteria  are  eompleteness,  eonsisteney,  eoherenee,  and  eorreetness 
(Paee  2000).  Completeness  refers  to  addressing  all  entities  and  proeesses  within  the 
domain  and  all  components  of  the  simulation  space  while  satisfying  the  specification  of 
the  simulation.  Consistency  ensures  the  entities  and  processes  are  addressed  from 
compatible  perspectives.  Coherence  checks  to  see  if  all  elements  have  a  function  and  all 
elements  can  be  activated.  The  last  criterion,  correctness,  is  more  general  in  nature  and 
refers  to  an  overall  review  of  the  model  for  flow  and  understanding  (Pace  2000). 

Verification  comes  in  part  from  the  comparison  of  the  completed  model  to  the 
requirements  set  forth  in  Chapter  3.  The  model  was  examined  and  an  element  was  found 
for  every  item  specified  for  representation.  Furthermore  elements  of  potential  interest  to 
the  model  purpose  were  addressed  indicating  a  high  level  of  model  completeness  and 
coherence.  Real  world  counterparts  exist  for  each  element  enabling  reuse  and 
unnecessary  elements  were  scrubbed.  Additionally,  each  element  is  addressed  from  the 
same  perspective.  Activities  were  presented  from  a  process  oriented  viewpoint  and 
entities  from  an  object  oriented  viewpoint  adding  to  the  consistency  of  the  model.  Lastly, 
correctness  is  ensured  by  checking  the  overall  flow  of  the  model  looking  for  logical  flows 
while  ensuring  no  disconnects  exist. 

The  validation  process  began  by  comparing  the  results  of  the  data  analysis 
methodology  to  similar  results  generated  by  NASA  personnel.  Taking  the  filtered  data 
and  importing  it  to  MS  Project  and  developing  a  IDEF3  schematic,  a  comparison  was 
made.  The  results  were  found  to  be  very  close  confirming  the  concept  of  using  the  start 
and  stop  dates/times  to  establish  precedence  where  none  was  given.  By  comparing 
NASA  flow  diagrams  to  the  IDEF3  model,  the  data  analysis  method  was  validated. 
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V,  Conclusions  and  Recommendations 


In  this  chapter,  conclusions,  recommendations,  and  suggestions  for  future 
research  will  be  discussed.  This  chapter  will  also  re-examine  the  scope  and  limitations, 
then  look  at  the  threats  to  validity  that  were  suggested  at  the  beginning  of  the  analysis, 
and  see  what  materialized  to  see  if  any  unforeseen  conditions  arose. 

Conclusions 

Beginning  the  modeling  process  with  a  detailed  conceptual  model  is  the  most 
appropriate  step.  By  working  at  the  Domain  Level,  the  baseline  eoncepts  and  flows  can 
be  gathered  providing  insight  into  the  data  required  and  the  data  currently  available.  This 
step  allows  the  researcher  to  gather  facts  about  the  system  to  be  modeled  and  eombine 
them  into  a  format  that  is  clear  and  concise. 

Using  the  IDEF3  methodology  provided  an  excellent  format  for  organizing  the 
data  and  presenting  it  in  a  clear  model.  The  use  of  a  few  basic  components  made  learning 
the  methodology  quick  and  easy.  The  IDEF3  methodology  matches  well  with  conceptual 
model  development  and  is  just  right  for  the  layout  of  process-centered  diagrams. 
Additionally,  it  adds  the  capability  to  diagram  object-centered  views. 

The  use  of  KBSEs  ProSim  7.0  provided  several  benefits.  The  software  was  easy 
to  grasp  and  allowed  for  the  collection  of  and  transformation  of  the  data  directly  into  a 
IDEF3  schematic.  The  interface  was  user-friendly  and  provided  several  ways  to  view  the 
data.  When  viewing  the  data  in  the  Process  Flow  Node  Fist  mode,  each  diagram  and 
block  was  represented  by  a  single  line  of  text  on  the  sereen.  Each  decomposition  could 
be  opened  or  closed  by  expanding  or  collapsing  the  tree.  In  this  mode,  it  was  easy  to 
move  objects  around  the  model.  Another  benefit  is  the  generation  of  the  model  in  HTML 
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format.  ProSim  generates  a  folder  that  eontains  the  model  components  as  individual 
HTML  files  that  can  be  opened  and  viewed  on  any  web  browser.  This  function  allows 
the  model  to  be  shared  with  others  who  do  not  have  the  ProSim  software. 

An  additional  benefit  of  the  ProSim  software  not  realized  in  this  effort  is  its 
ability  to  integrate  simulation  data  and  be  used  to  conduct  analysis.  ProSim  was  designed 
to  not  only  produce  IDEF3  schematics  but  to  be  used  to  conduct  simulation  analysis. 

How  well  ProSim  operates  in  this  capacity  or  whether  it  would  be  appropriate  for  use  in 
future  research  in  this  endeavor  is  unknown  at  this  point. 

Scope  and  Limitations 

Data  as  expected  turned  out  to  be  a  limitation  and  provided  a  challenge  for  the 
scope.  In  some  cases,  the  data  was  too  detailed  but  still  lacking  in  levels  of  precedence. 

In  many  cases  the  data  was  found  to  be  difficult  to  track  down.  Data  concerning 
operations  outside  the  OPF  was  especially  difficult  to  locate.  Data  outside  the  scope  of 
the  effort  had  to  be  filtered  out  based  on  the  judgment  of  the  researcher.  Additionally,  the 
bias  and  interest  of  those  at  KSC  influenced  this  problem  to  some  degree.  Three  main 
ongoing  concerns  at  KSC  concern  the  SSMEs,  TPS,  and  unscheduled  maintenance.  The 
first  two  generated  the  data  that  was  in  greater  detail  while  the  last  item  generated  data 
that  was  outside  the  scope. 

Threats  to  Validity 

Due  to  the  above  listed  focus  at  KSC,  time  and  resources  have  been  devoted  to 
collecting  data  associated  with  those  areas  of  concern  rather  than  all  operations. 
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Therefore,  data  concerning  engine  operations,  especially  within  the  OFF,  and  the  TPS 
exists  in  detailed  and  extensive  quantities.  A  list  of  5988  STS  procedures  was  provided 
to  the  researchers.  Of  the  425  different  STS  procedures  used  to  develop  the  current 
conceptual  model,  only  70%  were  found  in  this  list. 

Additionally,  much  data  exists  for  unscheduled  maintenance  and  the  associated 
troubleshooting.  KSC  spends  approximately  25%  of  shuttle  turnaround  time  on 
unscheduled  maintenance  (McCleskey  2003).  The  importance  of  analyzing  unscheduled 
maintenance  for  trends  is  seen  in  the  possibility  of  discovering  tasks  that  should  be 
performed  more  often  that  may  be  necessary  to  reduce  both  future  maintenance  actions 
and  turnaround  time.  These  tasks  are  not  included  in  this  model.  Some  activities  of 
concern  to  developers  of  next  generation  space  vehicles  may  have  been  inadvertently  left 
out  since  those  tasks  are  not  regularly  scheduled  or  recognized  as  needing  to  be 
scheduled. 

Data  Analysis 

The  most  difficult  data  to  analyze  was  the  data  found  in  spreadsheets  and  tables. 
The  spreadsheets  allowed  sorting  by  design  disciplines,  STS  subsystems  and  procedure 
numbers.  However,  lack  of  textual  description  of  the  process  or  overall  procedure 
(including  constraint  information)  made  model  developing  challenging.  The  researcher 
was  left  to  arrange  the  data  based  on  the  known  constraints  (remove  must  occur  before 
installation)  and  task  timing  (start  and  finish  times).  Without  the  benefit  of  process 
descriptions  and  constraints,  many  processes  were  modeled  in  parallel. 
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Using  the  supplied  data,  this  researeh  did  serve  in  verifying  that  the  methodology 
used  to  filter  and  serub  the  data  was  eorreet.  The  key  here  was  to  develop  a  baseline 
model  eneompassing  the  neeessary  aetivities  of  a  general  nature  that  may  be  useful  in 
developing  a  simulation  for  RSV  ground  operations.  This  model  serves  that  purpose  and 
is  useful  in  understanding  the  proeesses  involved  in  turning  around  a  RSV.  The  level  of 
data  available  was  useful  in  this  initial  baseline  approaeh  but  will  need  to  be  expanded  for 
researeh  to  eontinue. 

Suggestions  for  Further  Study 

This  researeh  effort  exposed  the  need  for  further  data  eolleetion  and 
deeomposition.  The  data  sets  examined  to  gain  a  baseline  understanding  of  the 
operations  at  KSC  are  not  suffieient  enough  to  provide  the  detail  needed  for  developing 
distributions  about  the  durations  and  arrival  rates  needed  for  simulation  development. 
Continued  researeh  into  the  eolleetion  of  this  data  and  its  analysis  would  be  benefieial  to 
the  furtheranee  of  this  effort  towards  the  development  of  a  simulation. 

However,  this  effort  was  tasked  with  developing  a  baseline  eoneeptual  model  that 
would  be  used  to  model  various  SOVs  making  tradeoffs  between  eomponents  and 
materials.  With  this  end  in  mind,  it  may  not  be  neeessary  to  eolleet  detailed  data  on  all 
aspeets  of  the  shuttle  operations,  but  only  those  deemed  neeessary  by  subjeet  matter 
experts. 

Additionally,  eontinued  researeh  into  unseheduled  maintenanee  on  the  shuttle 
would  be  benefieial  in  providing  greater  validity  to  the  model.  By  filtering  out  the  data 
without  further  examination,  some  neeessary  model  eomponents  may  not  have  been 
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modeled  simply  beeause  they  were  not  seheduled.  A  detailed  examination  of  the 
unseheduled  maintenanee  on  the  shuttle  may  expose  those  aetivities  that  should  have 
been  ineluded  and  provide  a  more  rigorous  method  for  fdtering  out  unneeessary  data. 
Appendix  C  eontains  a  more  detailed  listing  of  further  researeh. 
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Appendix  A:  Listing  of  Acronyms  Used  in  Model 


Due  to  space  constraints  and  the  time  consuming  nature  of  data  entry,  many  items 
names  have  been  replaced  with  acronyms.  In  the  body  of  the  document,  the  item  name  is 
spelled  out  for  the  first  use  but  that  is  not  the  case  for  the  model.  To  help  in 


understanding  the  model,  this  list  of  items  and  corresponding  acronyms  has  been 
developed. 


AFRSI 

advance  flexible  reusable  surface  insulation 

APS 

auxiliary  power  system 

APU 

auxiliary  power  unit 

AV 

avionics 

C/0 

check  out 

CCTV 

closed  circuit  television 

CEIT 

crew  equipment  interface  test 

COMM 

communication 

DPS 

data  processing  system 

ECLSS 

environmental  control  life  support  system 

ECS 

environmental  control  system 

EPD 

electronic  power  distribution 

ET 

external  tank 

ET 

external  tank 

FCP 

fuel  cell  systems 

FCS 

flight  control  system 

FRCS 

forward  reaction  control  system 

GH2 

gaseous  hydrogen 

GHE 

ground  handling  equipment 

GNC 

guidance,  navigation,  and  control 

GOX 

gaseous  oxygen 

GPS 

global  positioning  system 

GSE 

ground  system  equipment 

HMF 

hypergol  maintenance  facility 

HPFTP 

high  pressure  fuel  turbo  pump 
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HPOTP 

high  pressure  oxidizer  turbo  pump 

HUD 

heads  up  display 

HYD 

hydraulic  systems 

INS 

instrumentation  system 

KSC 

Kennedy  Space  Center 

LESS 

leading  edge  structural  system 

LH2 

liquid  hydrogen 

L02 

liquid  oxygen 

LP 

launch  pad 

LPFTP 

low  pressure  fuel  turbo  pump 

LPOTP 

low  pressure  oxidizer  turbo  pump 

LPS 

launch  processing  system 

MEDS 

multifunction  electronic  display  system 

MCC 

Mission  Control  Center 

MEQ 

mechanism 

MLG 

main  landing  gear 

MLGD 

main  landing  gear  door 

MLP 

mobile  launch  pad 

MPS 

main  propulsion  system 

MSBLS 

microwave  scanning  beam  landing  system 

MTU 

master  timing  unit 

NC 

numerical  control 

NDE 

nondestructive  evaluation 

NLG 

nose  landing  gear 

NLGD 

nose  landing  gear  door 

ODS 

orbiter  docking  system 

OEL 

orbiter  electrical 

OHE 

orbiter  handling  equipment 

OME 

orbiter  maneuvering  engine 

OMEF 

orbiter  main  engine  maintenance  facility 

OMEMF 

orbiter  main  engine  maintenance  facility 

OML 

outer  mold  line 

QMS 

orbiter  maneuvering  system 

OPF 

orbiter  processing  facility 

OPS 

operations 

OSO 

orbiter  support  ops 

OTC 

orbiter  conductor  operations 

PCMMU 

post  code  master  modulation  unit 

PLBD 

payload  bay  door 

PRSD 

power  reactant  storage  and  distribution 

PVD 

purge,  vent,  and  drain 

PYR 

pyrotechnics 
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QC 

quality  engineering 

R&R 

remove  and  replace 

RCC 

reinforced  carbon-carbon 

RCS 

reaction  control  system 

RPSF 

rotation,  processing,  and  surge  facility 

RSI 

reusable  surface  insulation 

SCOPALS 

scanner  closeout  preprocessor  and  lofting  system 

SME 

shuttle  main  engine 

SRB 

solid  rocket  booster 

SSME 

space  shuttle  main  engine 

SSME 

space  shuttle  main  engine 

STR 

structures 

TCID 

test  configuration  identifier  document 

TPS 

thermal  protection  system 

TVC 

thrust  vector  control 

VAB 

vehicle  assembly  building 

WCS 

waste  collection  system 

WSB 

waste  spray  boiler 

XDUCER 

crossducer 
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Appendix  B:  Baseline  Conceptual  Model  for  RSV  Ground  Ops 


This  section  includes  all  the  diagrams  included  in  the  model  in  the  order 
generated  by  Pro  Sim  when  exported  as  a  RTF  document.  The  RTF  was  then  converted  to 
a  MS  Word  document  and  imported  into  this  thesis.  This  collection  of  diagrams  is  meant 
to  aid  in  understanding  the  model  by  providing  a  physical  versus  electronic  version.  This 
collection  of  diagrams  is  meant  to  supplement  the  electronic  version  of  the  model  and  is 
not  intended  to  replace  it.  The  electronic  version  is  made  available  with  this  document  to 
aid  in  further  research  efforts  and  model  development. 
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Figure  B-1,  Overarching  Shuttle 


Description 

There  are  thousands  of  aetivities  performed  during  the  eourse  of  a  normal  OPF  proeessing  flow. 
For  the  most  part,  these  ean  be  grouped  into  the  following  three  major  activities:  Preparing  the 
external  surfaces  (e.g.  the  thermal  protective  tiles)  for  the  next  mission.  Because  of  improvements 
in  tile  repair  and  manufacturing  processes,  along  with  modifications  to  the  thermal  protection 
system,  this  work  is  not  typically  the  critical  path. 

Payload  related  work  in  the  Orbiter’ s  mid-body  or  payload  bay  and  crew  cabin.  This  activity 
includes  downloading  the  previous  mission  payload  and  its  integration  hardware,  and  preparing 
the  payload  bay  and  crew  cabin  for  the  upcoming  payload.  This  activity  is  typically  either  the 
critical  path  or  at  least  a  major  influence  on  the  critical  path. 

Work  in  and  around  the  Orbiter’ s  Aft  Engine  Compartment.  This  activity  includes,  sating  the 
OMS  Pods  and  Auxiliary  Power  Units,  removing  the  three  main  engines,  installing  the  next  set  of 
engines  and  performing  pre-flight  testing  of  the  Aft  Engine  Compartment’s  many  systems.  Like 
the  payload  related  work,  this  activity  is  either  the  critical  path  or  a  major  influence. 

Not  mentioned  above  are  many  other  important  tasks  that  must  be  integrated  into  the  flow  such  as: 
safing  the  FRCS  ,  changing  the  tires;  polishing  the  windows;  trouble-shooting  the  previous 
mission’s  in-flight  problems  and  a  host  of  minor  problems  that  occur  during  the  course  of  any 
OPF  flow;  and  performing  approved  modifications.  (Cates  Shuttle  Processing  Overview.ppt) 

Orbiter  Processing  Facility  (OPF) 

There  are  three  OPF  high-bays  available  for  Orbiter  Processing.  These  are  referred  to  as  Bay  1, 
Bay  2,  and  Bay  3.  Bays  1  &  2  are  co-located  and  Bay  3  is  located  a  short  distance  from  them. 

The  orbiter  processing  flow  begins  at  OPF  roll-in  and  ends  at  OPF  roll-out  to  the  Vehicle 
Assembly  Building.  The  orbiter  is  processed  in  one  of  the  three  OPF  bays  for  approximately  80 
Calendar  days  (62  Workdays)  of  OPF  Processing. 
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Figure  B-2,  Element  L«&R  Ops 


Figure  B-3.  Launch  Pad  Ops 
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Figure  B-4,  Orbiter  Processing 
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Figure  B-5,  Post-Flight  Ground  Handling 


Figure  B-7.  VAB  Ops 
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Figure  B-8.  System  Shutdown,  Safing,  and  C/O 


Figure  B-9,  SSME  Processing  @  LP 
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Figure  B-10.  TPS  Inspection 


Command 
Control  & 

►  Health 
Management 

3-1-1  1 

Environmental 
Control  & 

Life  Support 

3.1.2  1 

& 


Guidance, 
Navigation 
&  Control 

3.1.3 


& 


Cockpit  & 
Crew 

I'aneJ 

Communications 

3.1.5  1 

Figure  B-11.  ECS,  Crew  module,  GNC,  Life  support,  &  Comm 


Figure  B-12,  Ground  Systems  &  Facilities 
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Figure  B-13,  Payload  Accommodations 


Figure  B-16,  Safety  Management  &  Control 
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Figure  B-17.  Structures,  Mechanisms,  Vehicle  Handling 


Figure  B-18.  TPS  Processing 


Figure  B-19,  FT  OPs 


Figure  B-20,  Orbiter  Mating 
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Figure  B-21.  SRB  Ops 


Figure  B-22.  SSME  FRTs 


Figure  B-23,  Cockpit  &  Crew  Panel 
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Figure  B-24,  Command  Control  &  Health  Management 
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Figure  B-26,  Environmental  Control  &  Life  Support 
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Figure  B-27.  GNC 


Figure  B-28.  APU 


Figure  B-29.  FCP 
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Figure  B-30.  HYD 
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Figure  B-32,  GSE  Propulsion 
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Figure  B-33.  MPS 
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Figure  B-34,  OMS 
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Figure  B-35.  SSME 
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Figure  B-37.  STR 


Figure  B-38.  PYR 


Figure  B-39.  VPL 
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Figure  B-40.  TPS  Maintenance 


Figure  B-41,  Post  Flight  Inspections 
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Figure  B-42,  Orbiter  Mating  Ops 


Figure  B-43,  Inspect  Completed  SRB 
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Figure  B-44,  RPSF 


Figure  B-45,  Data  Processing  System  (DPS) 
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Figure  B-46.  INS 


Figure  B-47.  KU  Band 
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Figure  B-49.  ECLSS 
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Figure  B-50.  Fan  Package 


Figure  B-51.  NLG  Ops 
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Figure  B-51.  GSE  SME  Install  to  exit 


Figure  B-52,  GSE  to  SSME  Removal 


Figure  B-53,  MPS  to  SME  Removal 
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Figure  B,54,  MPS  SME  Install  to  Roll-out 


Figure  B-55.  OMS  Pods 


Figure  B-56,  OMS  to  SME  Removal 
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Figure  B-57.  OMS  Post  SME  Installation 


Figure  B-58.  Engine  Installation  to  OPF  Roll-Out 


Figure  B-59.  OMEF 
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Figure  B-60.  OFF  Roll-In  to  SSME  Removal 


Figure  B-61.  FT  Door  Operations 


Figure  B-61,  MLG  Assembly 


Figure  B-62,  NLG  Assembly 
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Figure  B-63.  ODS  Inspections 


Figure  B-64,  Corrosion 
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Figure  B-65,  Windows 


Figure  B-66,  AFRSI  Blanket  Maintenance 
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Figure  B-67.  FRSI  Maintenance 


Figure  B-68,  Tile  Replacement 


Figure  B-69,  Windows 
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Figure  B-70,  Lower  Aft  Fuselage 


Figure  B-71.  Lower  Forward  Fuselage 
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Figure  B-72.  Lower  Midbody  Fuselage 
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Figure  B-74,  Lower  Wing 


Figure  B-75,  OMS  Pods 


Figure  B-76.  Upper  Aft  Fuselage 
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Figure  B-77.  Upper  Forward  Fuselage 


Figure  B-78,  Upper  Midbody  Fuselage 


Figure  B-79,  Upper  Wing 
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Figure  B-80,  Vertical  Stabilizer 
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Figure  B-82,  Monitoring 
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Figure  B-83,  Monitoring  Functions 


Figure  B-84,  Engine  Installation  Operations 


Figure  B-85,  Existing  Engine 
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Figure  B-86,  New  Engine 


Figure  B-87,  SSME  Removal  Operations 


Figure  B-88,  Make  New  Tile 


Figure  B-89,  Lower  Aft  Fuselage  Macro 
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Figure  B-90,  Lower  Aft  Fuselage  Micro 


Figure  B-91,  Lower  Forward  Fuselage  Macro 


129 


Figure  B-92,  Lower  Forward  Fuselage  Micro 
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Figure  B-93,  Lower  Midbody  Fuselage  Macro 
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Figure  B-94,  Lower  Midbody  Fuselage  Micro 
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Figure  B-96.  Lower  Wing 
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Figure  B-97.  OMS  Pods  Macro 


Figure  B-98,  OMS  Pods  Micro 


Figure  B-99.  Upper  Aft  Fuselage  Macro 
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Figure  B-100.  Upper  Aft  Fuselage  Micro 


Figure  B-101.  Upper  Forward  Fuselage  Macro 
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Figure  B-102,  Upper  Forward  Fuselage  Micro 


Figure  B-103,  Upper  Midbody  Fuselage  Macro 


Figure  B-104,  Upper  Midbody  Fuselage  Micro 
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Figure  B-105,  Upper  Wing  Macro 


Figure  B-106,  Upper  Wing  Micro 
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Figure  B-107.  Vertical  Stabilizer  Macro 


Figure  B-108,  Vertical  Stabilizer  Micro 
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Figure  B-109,  NC  Programming 


Figure  B-110.  Physical  Model 


139 


Process / 
Landing 
Prep/Recovery 
Ops 

Process / 
Post-flight 

Ground  Handling 
&  Transport 

Process / 
Orbiter 
Processing 


Figure  B-111.  Orbiter 


Process / 
Existing 
Engine 


SSME 

Serviced' 


SSME  at 
OPE 


Process / 

Process  /  Engine 

Transport 

Installation  to 

SSME  to  OPE 

OPE  Roll-Out 

Figure  B-112,  SSME 


■2 


Process  /  NC 

Milling 

Machine 


Process  / 
Measure 
Step/Gap 


Figure  B-114,  Tile  R&R 


14 


■3 


Appendix  C:  Future  Research 


This  appendix  seeks  to  expand  upon  the  future  research  discussed  in  Chapter  5. 
This  section  has  been  broken  into  categories  with  potential  areas  of  analysis  listed  within 
each.  Some  of  the  subcategories  can  be  taken  alone  or  combined  for  further  research. 


Data  collection  and  analysis 

Data  is  available  from  several  sources.  NASA  has  partnered  with  various 
agencies  such  as  AFRL  and  has  shared  data  with  them.  Within  AFRL,  several  offices 
may  have  data  collected  independently  of  other  sources.  A  listing  of  each  office  working 
with  space  shuttle  data  would  be  very  helpful.  Additionally,  the  current  maintenance 
contract  holder,  United  Space  Alliance,  would  be  a  good  source  of  information.  One  of 
the  difficulties  experienced  was  asking  for  the  data  using  the  correct  terminology;  for 
example,  what  NASA  calls  a  work  breakdown  structure  is  not  necessarily  what  the 
researcher  has  requested.  Some  areas  of  future  research  within  this  area  are  as  follows: 

-  Develop  a  user  friendly  information  system  to  capture  both  component  and 
subsystem  level  logistics  information  (MTTF,  Repair  Time,  failure  rate 
distributions,  etc)  from  research  and  development  through  Concept  Refinement 
and  Technology  Development  (Milestone  B)  to  enable  Simulation  Based  R&D 
and  Simulation  Based  Acquisition  model  development. 

-  Develop  methodology  to  collect  and  document  component  and  subsystem  level 
logistics  information  (MTTF,  Repair  Time,  failure  rate  distributions,  etc)  from 
past,  present  and  future  reusable  space  vehicle  operations  to  enable  Simulation 
Based  R&D  and  Simulation  Based  Acquisition  model  development. 

-  Identify,  quantify,  and  incorporate  into  conceptual  model  space  shuttle’s 
“unscheduled/troubleshooting”  activities  (propulsion,  power  management, 
thermal  protection,  etc. . .). 
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System  Comparisons 


The  space  shuttle  is  not  the  only  vehicle  to  be  used  as  a  baseline.  Therefore  it  is 
necessary  to  look  at  the  other  baselines  on  the  aircraft  side  of  the  spectrum.  Also,  any 
simulations  existing  for  aircraft  systems  would  be  of  interest  and  should  be  examined. 
Another  area  of  interest  would  be  the  logistics  surrounding  expendable  launch  vehicles 
(ELY). 


-  Compare  and  contrast  the  ground  facility/logistics  requirements  for  rocket  and  air- 
breathing  propulsion  systems  for  use  on  reusable  space  vehicles  (maintenance, 
fuel,  etc...). 

-  Compare  and  contrast  the  ground  facility/logistics  requirements  for  current  and 
potential  future  thermal  protection  systems. 

-  Investigate  the  difference  in  logistics/maintenance  requirements  for  manned  and 
unmanned  reusable  launch  vehicles. 

-  Investigate  the  ground  facility/logistics  requirements  for  the  aircraft  selected  as 
the  baseline.  Locate  and  analyze  any  existing  simulations. 

-  Investigate  the  ground  facility/logistics  requirements  for  ELVs.  Locate  and 
analyze  any  existing  simulations. 

Simulation  Generation 

-  Develop  simulation  modules  for  “design  disciplines”  identified  in  this  document 
(propulsion,  power  management,  thermal  protection,  etc. . .)  based  upon 
planned/scheduled  maintenance. 

-  Develop  simulation  modules  for  “design  disciplines”  identified  in  this  document 
(propulsion,  power  management,  thermal  protection,  etc. . .)  based  upon 
unscheduled/troubleshooting  activities. 


Investigate  other  simulations 

-  Compare  and  contrast  simulations  under  development  by  NASA,  AERL,  and 
other  government  agencies.  Examine  modules  included,  level  of  detail,  and 
reasoning  behind  development.  Look  for  level  of  detail,  systems  included,  and 
precedence/flow  logic.  Then  compare  to  the  baseline  conceptual  model  in  this 
research  and  to  the  simulations  being  investigated. 

Compare  and  contrast  NASA’s  Shuttle  Op’s  1 .0  to  existing  AERL  and 
contractor  simulations. 
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